Blender UI paper cuts

Hi @eobet, luckily that’s no bug. Hiding just has influence on the viewport display. and baking is treated as rendering. So just deactivate the lights in render for that purpose.

disableinrender
Btw. Reflectioncubemaps still work being hidden.

1 Like

Thanks, but again, horrible inconsistency and added complexity for new users! :frowning_face:

2 Likes

Yes but think about it that way. A cubemap is just a texture. So what is displayed on your reflective materials just the saved texture. And hiding something in the viewport is updating everything correct what is rendered live. You can see that reflections on your material are rendered by eevee and are hidden if needed. But the texture isn’t changed. And if you would want to have it react live to the hide flag. You would have to bake, cache each cubemap texture 2 times for a single light. And now think of a multitude of lights with parts of them hidden. You would need a giant amount of textures cached for that. Or alternatively you would have to rerender every cubemap by such a change.

In short. Basically it’s an extra step to bake textures and they are not just bound to the realtime rendering. I see what you mean, why you want it to react to hiding, but it can easily be seen the other way as the baking is technically not part of the realtime display step just the final texture is. No matter which way you decide here. It would feel partially wrong.

No, my main point is that a new users probably expects that hidden objects are hidden even in baking/renders.

It’s the advanced users who should have to unhide that extra filtering option and fiddle with it, not new users. Blender still puts most of the burden of complexity on new users, instead of shifting it to advanced users.

Also, regarding baking/lights visibility, as a new user (or even a regular user) I don’t really care about the techincial explanation. I just know that my user experience is inconsistent and that is bad. Again, a burden of complexity placed on new users (that may not easily be shifted, but auto-baking could be an option for visibility changes too).

Hmm, ok you want the “Hide in Viewport” to overwrite or override “Disable in Render”. But that will have severe consequences on workflows, eg where you want the workspace to be cleaner and the render to contain everything. That’s a far reaching change…

Wouldn’t it be easier for your goal if the hide in render would by default be visible, that a new user would recognize it. Perhaps update the Bake Button to contain an additional info that its “Rendering” and we are good to go?

Yes Auto baking would be nice, but in Eevee it would have a big impact on performance especially if you changed it from reacting on the render flag to the hide flag. So this could be a solution that all textures are rerendered before usage in viewport or a final render, but on the cost of rendertime.

And if not rebaked all the time and you have a difference between what is seen in the render and what is seen in the realtime viewport. A saved version will be incorrect in the one case or the other, but it will always be wrong somewhere.

And I think it’s benefitial to be able to have a difference between render an viewport visibility. You probably see that differently right now, but think about it’s consequences first. There is no simple decision here what will be good.

Haha, this was the case in early 2.8 alphas. :smile:

Still places the burden of complexity on new users, instead of the other way around, as I described above.

It is what it is, but this is my feedback.

1 Like

:slightly_smiling_face: Ok.

Can I ask the UI team about the use of the ‘:’ in the Interface.

As an example the Filter drop down in the Collections Panel uses them whereas drops downs like the ViewPort Shading don’t.

If the Design Standard is to use them or not, let me know. I have time on my hands and will submit patches.

1 Like

This felt apt as it appeared just now in my Twitter feed.

Here is again someone who is new at Blender* and who also experienced what I said in that Blender throws all complexity at new users, instead of shifting it to advanced users who are better equipped to cope with its idiosyncrasies:

[*] And note that a new user doesn’t stay new forever, so their feedback is invaluable while they’re in that stage!

LOL. What was he expecting, he never heard of blender before or what?
He should know from the start that blender is the least intuitive 3d software on the market.

Nobody wants it to be, and that is why we post here for the developers to see.

But I did not post the link to laugh at the state of Blender. There is actual useful feedback in there (I too tripped up a bit today actually because I wanted to make my first rendered animation, and the “render animation” menu entry just launched a render window and doesn’t let you even choose a camera, for example).

2 Likes

I agree to that in many points @eobet. Don’t get me wrong here. Just like you I think blender has to gain ground in many aspects to make it more userfriendly and easier to grasp. Many settings are splattered across or “hidden” within the gui in unexpected places, or simply are designed too complex.
But I can hardly see that we are getting heard here at all, it’s very frustrating.

Once again, AutoBake mode that supervises visibility flag changes might be a really good idea to ease that problem.

I just disagree that a user, new or not, will be unable to differentiate between two icons in the outliner, one for hide in viewport and another hide in render.
New user aren’t dumb, they are just new, very often they even aren’t new to the subject, just to the tool, so if both icons were there by default, and if the BakeButton would be titled “Bake Rendering to Cubemap” then everybody would get it. I don’t understand why you are laughing about both visibilitiy options being visible, C4D has also both render and viewport settings available directly and is an extremely userfriendly tool.

I totally agree with your statement to make things easier by default and put complexity to optional tweaks, it’s just unspecific. And by changing the hide in viewport to something that changes also rendervisibility, I don’t think we were on the road to make things easier.
Instead “Hide in Viewport” should no longer be the default icon, but another new “Deactivate” icon that unifies all submodes for hiding and greys them out (“Hide in Viewport”,“Disable in Viewport”, “Disable in Render”, “Selectable”) to signalize they are controlled indirectly. Or perhaps a system of tristate icons like C4D has is even better.

But there have to stay indiviual visibility settings for viewport and render. And then the render cubemap problem will also stay. The Autobaking has to be deactivatable for performance reasons and a user will at some point be confronted the first time with a cubemap not fitting the viewport display or the render result is wrong.

But enough of that, take a look at this guy. Quite fitting too. He’s no newbie at all, just new to blender:

4 Likes

I made a few of those videos myself, and most of it is actually fixed now (just a hair under a year later, and a few more things is coming in 2.81), which is great progress! :+1:

Let’s hope his issues get fixed too. I heard Blender has a dedicated UI developer now (although I don’t know who it is and if they were mentioned in the Blender conference, I must have missed it).

1 Like

we can admit that this is not designed among the best … maybe we could directly choose the desired fallof without having to dig through the menus :wink:

bad
@pablodp606

12 Likes

UI: Text Alignment Improvement.

I’d like to make a suggestion for alignment in all drop down panels more specifically the alignment of the text for groupings, within Panels/Drop Downs

I’m assuming the Text Indentation was a design decision to aid in identifying groupings within the Panel/Drop Down lists?

I think think it would be better and cleaner for the interface if the text was left aligned and I don’t think you lose anything to do with clarity.

Funnily enough, look what her majesty autodesk says:

2 Likes

Lock Vertex :
Now the 2 workflows to lock vextex in edit mode, at least the ones that I know, are hide if you want to lock them, but you don’t have visibility, or to use the shape keys, you can modify the whole mesh but you “save” that vertex positions in object mode, I think it would be nice to lock the position and add a color too, the same workflow as the mark sharp or mark seam, and keep the visibility that way.

Autodesk wrote that? Wow that’s really wonderful. Great to see mutual respect amongst software like that.

1 Like

Yep, unbelievable, they did!

https://www.autodeskonline.com/comparisons/maya-vs-blender.html

Actually it’s AutodeskOnline.com (GoClickGo Marketing Inc.), not Autodesk Inc. itself.
But anyway they are authorized partners

There is a disussion about it.
This problem is not so easy to handle)
Addons list can be easily too long to scroll, while workbenches list is mostly defined.