Ok, I will do the next time that this happens.

One thing is that the bug is shared between all blender versions... so If I have the problem with blender 3.1 o 3.2 I cannot open 3.3 also.

In T98723#1371749, @Richard Antalik (ISS) wrote:

@Alberto Velázquez (dcvertice) Please download alpha build from https://builder.blender.org/download/daily/ and run file blender_debug_log.cmd. When problem happens, close Blender and upload created files. Hopefully there will be some error message present, I would expect crash if window fails to initialize.

I don't usually export in OBJ, so I don't know if the default options are asl correct for exporting vertex color. But I have not been able to get max or windows viewer to find a vertex color channel in any of its forms (vertex, facecorner) or types (color or byte).

Ok, I will do, but probably I will need some time to show a log.

In principle, I can think of two ways.

@Omar Emara (OmarSquircleArt) I have same opinion that you, but it will create a lot of insecurity in users. Cannot be the user warned in some way? It will be hard for user to know this limitation without trial and error.

Just to be clear, it is very difficult to reproduce, it can happen to me 3 times in a row and then not happen to me for 2 weeks.

I created a blend test file

I'm checking that same problems happens with all importers that I have tried (OBJ/GLTF) so I suppose that all exporter are affected.

In T93594#1266452, @Germano Cavalcante (mano-wii) wrote:

Needs more feedback from developers and artists.

Hi @Francesco Siddi (fsiddi) In my experience it is very easy for people not to see the problems of a UI/UX in the future and only focus on the positive and visual part. Moreover, it is the most normal problem that we users have had with the UI/UX changes in blender since a few years ago and that has led to many revert and unnecessary changes if this had been taken into account. But if we talk about things that affect modelers it is normal that nobody in the environment close to the developers take into account the workflow and the implications in the whole UI system of blender and its philosophy.

Since the thread is closed I will quote the main developers to take into account all the problems I have discussed.

As the person who designed the tool header concept I have to say that it has completely broken the idea and its usability has been severely damaged by poorly argued reasons.

This is not true. I have never changed a keyboard layout to use a program and I don't know nobody that do this. It is not even installed as default in windows.

I don't know how many problems will have between hundreds of different keyboard distribution. But only between UK and Spanish latinamerica you have one, for example. Don't have sense have 10-20-40 keys mapped for each distribution in the world.

In T88071#1165493, @Ludvik Koutny (rawalanche) wrote:

In T88071#1163664, @Pablo Dobarro (pablodp606) wrote:

I would strongly recommend not using the ~ for mode transfer. That key is not directly available in many keyboard layouts and it will be mapped to a functionality that should always be directly exposed in order for some modes to be functional. As an example, 2 of 4 keyboards I'm using in my computers don't have that key.

This is artificially constructed problem. Blender easily allows to map same operator to multiple different keys, so there's nothing preventing the keymap to have the tilde key operator mapped multiple times also for the keys in place of tilde in other regional keyboard layouts. Also, you are just offloading that problem to a less used feature, but it will still be there when one tries to use that less used feature, it won't go away. But a key that's directly under escape is a very valuable key reach-wise, so mapping it to something not very useful just because it changes in regional keyboard layouts is just lame solution.

In T88071#1163664, @Pablo Dobarro (pablodp606) wrote:

I would strongly recommend not using the ~ for mode transfer. That key is not directly available in many keyboard layouts and it will be mapped to a functionality that should always be directly exposed in order for some modes to be functional. As an example, 2 of 4 keyboards I'm using in my computers don't have that key. Most 60% keyboard layouts will have that key mapped to escape in any keyboard distribution.

Proposed solutions:

• Map Mode Transfer to the 1 key and shift all shortcuts one key to the right.
• Replace Object Mode by Mode Transfer in the 1 key and make Tab return to Object Mode when in any other mode.

My problem with this addon is that it is more complex, much more, than my basic idea, which is very simple, just some hotkeys linked to some colors. While the addon, which I have tested in the past, is much more complicated to use, with different solutions for many levels of users.

The feedback is obvious, the current implementation makes it unfeasible to use this feature.

maybe I'm wrong, but as I see the current modifier system I don't understand that a geometry node is not a modifier at the same time. I understand that the goal is that all nodes are modifiers and that these are internally a simple geometry nodes with a single node and all outputs exposed. Ok that exposing as modifier some node does not make sense and will not be done, but what sense does it make to maintain two different modifier systems when the modifiers are simply a linear geometry nodes?

Houdini is not the hardest software to learn, probably is the most easy software to learn. Four concepts about nodes and you can create everything that is impossible in other software in a day. It's hard to use for basic things like modeling because is not the target of the workflow, but not because the nodes. Jump from any software to houdini is easy, jump to Maya or modo is hard.

Yes

It is normal that the "Hide Collection" keys are prone to error because we have been warning for two years about the total failure of the redesign that was done, which was completely broken ignoring all warnings. Thus destroying the greatest virtue of blender in fast modeling.

Voxel remesher needs a way to block the slider from very low vixel size respect the object. Calculate the bounding box and that the slider won't change below some value like 1/500 of the size without input the text directly. Some for default value, that need to be a round number using the size of the object (1cm, 10cm, 1m, 10m, etc)

They are an old mockups that I made one year ago, but I think that the basic ideas still working. Please, ignore the other parts of the interface because it was part of a bigger proposal.

I will not go into the part of how to manage the data of the brushes. But regarding the idea of the list of brushes and other ideas of UI I see a quite fundamental problem. It is mixing tool with tool list. It is not the same and users are not interested in having both things mixed in the same panel.

Internally I do not know what limitations there are, but I completely agree with Pablo Dobarro.

It seems a complex system for something that should be simple from the user's perspective.

I will create a new bug report for the normal map.

@Brecht Van Lommel (brecht) I don't understand, that happens also without shadows.

In this other example the problem is see more clear

It's not because bounding box, same problem happens if you use 3d cursor, individual origins and active element.

The problems of that proposal have already been seen, such as the fact that half of the sidebar was occupied by only a dozen addons if at all. That increases the steps to access any tool. And that in small monitors the problem is even worse.

I have change the proposal a few because I see people don't understand correctly.

As I see it, except for limitation, I don't understand that nodes are not separate objects instead of modifiers. More so when the node tree can generate objects as primitives and can have multiple outputs.

@Harley Acheson (harley) Could be a good moment to solve the problem of the fram number?

In D7410#181013, @Harley Acheson (harley) wrote:

Another variation:

Although.. and no laughing... I honestly have no idea what the "(1)" represents to the left of "Cube.002)"

The @CobraA (CobraA) solutions is the best to read the text and separate numbers.

In D7410#180965, @Harley Acheson (harley) wrote:

@Alberto Velázquez (dcvertice) - Don't you have the option to use bold in fonts?

Getting any like real bold would require some work in our text-drawing code to support FreeType embolden. Otherwise we only have overprinting, which looks really blurry at low dpi. We can do changes of text color of course. Or add a background scrim to add contrast. Depending on what you are wanting to achieve.

other option is to use the | symbol insteado of /

That is possible too. Although I am personally allergic to that "pipe" symbol for separator.

@Harley Acheson (harley) Don't you have the option to use bold in fonts?

I will propose the same that in devtalk, a mix system that pick the addons list form this concept and the classic tabs that allow easy access and fast access

It happened to my when I'm trying to reproduce this bug T75618, when I pulse the render image element in the render menu. I don't know if it is related.

Tested, It work for me, also I think that need less time to boot that before

Mmmm, now the bug happens in my blender2.82a install. Anyone have seen this?

If blender2.83 open correctly when you are inside and open a new window, for example preferences, the problem can be the same and create a blank window that freezed the program

I can confirm the bug in the 1239cab11ff9 version, the last that work that I tested was the 6f4dbb661f10. And I can confirm that sometimes blender open normally

I can confirm the bug with today build in windows 10 64bits.

OK, I only closed the bug by petition of a dev by blender.chat.

In T53553#902444, @Ray molenkamp (LazyDodo) wrote:

i'm not sure if i can repro it in the current state, but while testing D6675 this one was real easy to trigger, as soon as the blender window does not have the focus you lose pressure

I cant reproduce the bug actually

In D3203#174736, @Brecht Van Lommel (brecht) wrote:

The argument is not that there shouldn't be nodes. It's that there shouldn't be separate baking nodes and shading nodes, with a loose coupling between them.

In D3203#174683, @Brecht Van Lommel (brecht) wrote:

An important Blender design principle is "Simple things should be simple, complex things should be possible".

In D3203#174572, @Brecht Van Lommel (brecht) wrote:

In D3203#174571, @Alberto Velázquez (dcvertice) wrote:

How many steps will be needed to do the same in the solution that you propose?

Approximately the same amount of steps. Maybe fewer, I can imagine this being possible with 3 steps since I'm not sure why you'd need to bake twice, if there are dependencies between maps they could be figured out automatically. Though that's possible to implement in either system.

In D3203#174542, @Brecht Van Lommel (brecht) wrote:

@Alberto Velázquez (dcvertice), setting up baking nodes like that would definitely be more work than my proposal. It can be argued that it's more powerful (it's not clear to me that it is in ways that really matter), but both for users and for the implementation an additional node system is going to be more complex. To be honest baking nodes is not an option I would seriously consider. If you want that kind of more complex but specialized/powerful workflow I think an add-on is suitable. For native Blender features we should aim for something simpler.

In D3203#174520, @Brecht Van Lommel (brecht) wrote:

To me it seems better to do something specifically for baking. Let me expand a bit on what the UI for a "baking material" could look like. In the material properties or shader editor, you'd have a "Add Baked Material" button. This would create a new material datablock, with as contents a Principled BSDF nodes and one or more Bake Texture nodes connected to it (or not if it doesn't make sense for e.g. Curvature).

Maybe this would just be a fixed default set, maybe it would look at the existing materials to see which parts needs textures and which parts have a fixed value, maybe there's a popup that let's you easily choose which channels to bake. Once this is added you can go and edit parameters in the various nodes. Due to the presence of Bake Texture nodes, there would be a Baking panel visible with material wide baking settings and a Bake button.

If you want to change the channels to bake afterwards, you can remove or add Bake Texture nodes. The Add node menu could have a category for that, for common channels like Base Color, Metallic, Roughness, Normal Map, Curvature, etc. Adding a bake texture to an input of the Principled BSDF could also auto detect the right type of channel to bake. Image file names could also be set up automatically based on object/material name and channel.

The baked material would be added outside of the regular list of material slots. The exact UI for that I'm not sure about. Maybe it's in the material slot list separate from the rest, with a specific icon, or in a completely separate material slot list where you can toggle between input and baked material slots. But regardless, this would be an actual material that can be used by the viewport, renderers and exporters.

In D3203#174533, @Ludvik Koutny (rawalanche) wrote:

In D3203#174520, @Brecht Van Lommel (brecht) wrote:

In D3203#174437, @Ludvik Koutny (rawalanche) wrote:

But if you look at the average baking workflow from the high level user stand point, then what people are mostly interested is just "I have this thing, and I want to bake these specific material channels into this particular UV channel and save them as the textures in this format at this file path.". That's pretty much all in 99% of cases.

In your workflow you join everything you want to bake together in one object. But from what I understand, there are two users here arguing it needs to work for multiple objects too. Not multiple texture sets on one object, but the same texture set applied to multiple objects. One of the main reasons asked for multi-object editing in Blender was to be able to pack UVs for multiple objects together, this is not uncommon.

The other things you're not addressing is how to preview baked materials in Blender, how to export materials to file formats like glTF or USD, and how to handle the case where you want to bake materials for use in Blender itself.

So I just don't how this covers 99% of use cases, I wouldn't generalize so easily.

Well the issue here is that if you want to actually bake same texture set on multiple objects, you first need to ensure that the UVs do not overlap in between the objects. So for example if there is object A and object B, then if the destination is the same texture set, then no UV isles of object A can overlap with texture isles of object B. This is tricky, as the only way to get that right is if both were originating from the originally combined object. So this would come down just to the order of operations. Either first detach, then bake, or first bake, and then detach. Baking of multiple objects alone should not be an issue with proper multi-object editing. Clicking bake button with multiple objects selected would initiate the bake on all of them, using their individual bake setups. Baking multiple objects to the same texture set though, that to me just seems like a messier, more chaotic way of doing the same thing as baking one object and then detaching pieces of it.

But as I said, I will just wait how your idea turns out and complain only if the things are too cumbersome to use that way.

If I take a step back from the specific, my general concern is just having to perform way too many manual steps to get the baking working. Which is especially the case with the current baking system in official Blender release.

In D3203#174423, @Brecht Van Lommel (brecht) wrote:

In D3203#174419, @Alberto Velázquez (dcvertice) wrote:

And unlike blender, substance is a closed software, it lets you see some specific maps that it decides are the ones you need to see, not others. Blender is a suite with many more possibilities and particularities. In substance you can't bake lightmaps, AOVs,... How do we show the Ambient Occlusion or the curvature? They are not input textures in any shader.

Right now if you use Solid draw mode with colors set to Texture, what you see is the active Image Texture node. In my design there would be a Bake Textures node for AO or Curvature in the material (not necessarily connected to anything), and activating it would work exactly like an Image Texture node.

In D3203#174413, @Brecht Van Lommel (brecht) wrote:

To me this reads similar to "realtime viewport rendering is not important, just press F12".

You can go through exporting to another application before you can see that you didn't have quite enough texture resolution in some part of the model or that the UVs were too stretched, but surely that's inefficient? Wouldn't it be much better to see the model with baked textures applied in the Blender viewport immediately after you've pressed Bake? Isn't that a standard feature in applications like Substance Painter?

In D3203#174392, @Brecht Van Lommel (brecht) wrote:

In D3203#174388, @Alberto Velázquez (dcvertice) wrote:

I don't see materials like a good place to have bake settings. A bake is independent of a material. I can bake an object with a lot of materials or without materials, or make a bake that have nothing to do with my actuals materials. A bake is like a function of everything nodes, socar addon or a script. Is a independent element that have low poly meshes, high poly meshes, some parameters and outputs. And all that parameters inputs and outputs can change in any moment

You can say it's independent of a material, but that still leaves the question about how to preview the results and more importantly, how to export the baked materials for your model.

Would you set up both these baking nodes and a material that uses the images resulting from these baking nodes for that? Isn't that redundant?

I don't see materials like a good place to have bake settings. A bake is independent of a material. I can bake an object with a lot of materials or without materials, or make a bake that have nothing to do with my actuals materials. A bake is like a function of everything nodes, socar addon or a script. Is a independent element that have low poly meshes, high poly meshes, some parameters and outputs. And all that parameters inputs and outputs can change in any moment

In D3203#174341, @Matthias Thurau (Zweistein) wrote:

I highly disagree. Nearly every other functionality in Blender is on a per object basis. If you want an Operator, material, texture, Physics, particle or any other kind of System to work with multiple objects, you either group the objects or script it to make it repeatedly for multiple objects. So many people waiting for this feature and it is getting postboned every release. You should put it in on object basis which is the most common usecase and extend funtionality to "on scene Basis" later. It would be one of the first function on a scene basis, but if you really need it you can do it later.

I believe that this system, even with all the improvements that can be made with respect to the previous one, which has undoubtedly cleaned up the code and everything in terms of programming, still contains very basic problems with its use.

Maybe I uploaded a wrong dae file, but the first time that I did this in my PC it worked.

I'm not against more brushes and keeping the original patch, which is what it should be. But if that's a problem to implement, then let it be masked only.

Cube Projection

I don't understand @Pablo Dobarro (pablodp606) and @William Reynish (billreynish) answer. Nobody have asked to have a "custom" brush in the a modifier key, we only want the only brush that we need to work. The mask tool. And the "shift" have no reason. I want to use shift, alt, ctrl,... not only shift. To map correctly invert, smooth and mask.

@Julian Eisel (Severin) Any date when this will be implemented? Face groups are very important to the sculpt process and I don't understand that we should be waiting months for something that is already implemented.

The brush work great, but one question. I hardly see differences (probably because the in progress status) between the different modes of the brush. Specially the Grab mode. I think that I will wait that in that mode or similar, I can grab a part of the mesh and see the cloth tension effect in the border of my brush. Similar to the pinch.

I think this idea is a mistake. All information must appear in the header area. You can't separate the parameter from the shorcut needed to change it and you have to be passing from one bar to another to know which hotkey is the one you have to press.

In T68970#844304, @Julian Eisel (Severin) wrote:

Like Campbell said, this is a design that's meant to avoid conflicts. Both action and selection are on the left mouse button now (unlike in 2.7, even with LCS) - how do we know if a mouse press intended to select, or execute the active tool action, like box-select? The click event allows differentiating.

I want to remember, that actual blender Multires baking is not reliable, because the bake is incorrect in at least the normal map baking.

It is a pleasure to read this proposal.

In that case the behaviour is perfect IMHO

The idea is good, but after test in 2.82 it doesn't work properly. The scrollbar is wide when it must to be and thin when the mouse is over the scrollbar.

old proposal that solve the problem using the same idea that vertex groups weights

I think that the impression that it is not useful is wrong. Most people didn't know the tool by that moment, but also is a important feature for a lot of situations where you need add precise normals

I have seen that add/multiply or paste a custom vector was removed when is one of the main applications? why it was done? It's remove a big feature of the custom normals.