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

Then have some reason that when I bake a simple bevel and load this happens in the normal?

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.

I agree with Severin that everything has to be part of something bigger. But Pablo in a few months is giving life to changes that we had been asking for years and that never arrived because of design decisions.

I tried in other PC and the problems persist in all the UVs channel... but If I try deleting the rest of the scene, saving and do the same it works.

I have tested the scene, in my macos it works with last master, in my windows computer it doesn't work.

I want to ask not only for actual render passes in the viewport, also we need artist useful passes, for example roughness.

Any update about this problem?

Oh, yes, my fault. I thought that we have talking about default sculpting parameters.

Other thing, Default Layer Height, to 0.2 or 0.1

It's not the most common, is the most common if you work with characters. When you are working any thing, a terrain, a object,... and begin to sculpt you don't expect that the mirror is activated. It's an option prone to errors.

In D3203#143177, @Piotr Adamowicz (madminstrel) wrote:

i think that bake jobs is the better option. in that jobs you indicate.

• the lowpoly objects (maybe with collections or other)
• The highpoly objects (with other collection)
• The UV map
• The Material Filter
• The passes

And inside the passes

• If the objects must to use multires to bake (not like now that you indicate it out)
• if the objects must to bake only same name meshes

Probably the option to implement that is inside Image editor or a new editor. I know that it's strange tell that, but I don't see why bake must be inside properties of an object.

IMHO baking is complex enough that it doesn't lend itself well to traditional UI design. I wrote an addon called Meltdown (no longer maintained) that tried this, but to achieve the flexibility I needed from the baking system as an artist, the UI had to be extremely complex and arcane. I wasn't very happy with that.

But baking could be a perfect fit for nodes.

Each nodegraph would constitute a job to be completed together and specify however many source, cage and target meshes or collections, and however many passes, material overrides and outputs the user desires.

Bake graphs could then be fired from the traditional Render panel, or straight from the node editor.

This would maximize flexibility while eliminating UI clutter from arcane and rarely needed functionality.

In fact, someone over on Blenderartists has created a node-based baking UI over here:
https://blenderartists.org/t/addon-bake-wrangler-b0-6-node-based-baking-tool-set-updated/1187732

While this addon is extremely incomplete, it's very promising and looks like a good place to start.

Also mirror off by default.

In D3203#143032, @Lukas Stockner (lukasstockner97) wrote:

Note that the patch already will bake the passes on all selected objects.

As for the argument of having the same passes on a lot of objects - hm, yeah, I can see why that would be useful. I'm not sure how to do this properly - it would be possible to add an option for "use the bake passes of the currently active object for all selected objects", but that's starting to drift back into the obscure unintuitive workflow that we have right now. Maybe add an option in the Input panel for "Bake *To* Collection"?

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

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

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

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

It's a good first step to improve the bake system. Anyway, I think that the main problem of the actual implementation of baking is that it is by object. It's is a error, because we don't need bake only one object, I need to bake 10-20 objects that use same materials but they are different objects. Because other way I'm obligated to use a proxy object to bake. Similar problems if I'm baking a lightmap ¿How we bake a lightmap? joining all objects in one? it's not practical.

So, the base of the system must be not ligated to the object. The bake must be separate "nodes" that make reference to what objects must to bake (with a list of objects, a collection or maybe materials) and made all this process automatic. And must to allow that objects will bake only with same name objects, or maybe other solution, to avoid problems baking.

Other problem of the actual system, not this patch, is that the system apply the border dilation in each bake, not at the end of the bake. It make taht the dilation can overwrite other islands pixels, depending of the baking order.

That doesn't make any sense. Yes, we should be able to bake multiple objects at once, without manually clicking bake on each, but the setup of all the baking needs to be individual per object depending on materials and UVs.

that dont have any sense. if I want to bake the same AO map in 500 objects I must to configure in each object all the passes, options and file path?

Depends on workflow. If you are baking let's say GI from Cycles for Eevee then it needs separate workflow, but if you are baking PBR map sets for game engines, then yes. Generally speaking, the problem right now is that these two very different workflows are mixed into one tool.

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

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

It's a good first step to improve the bake system. Anyway, I think that the main problem of the actual implementation of baking is that it is by object. It's is a error, because we don't need bake only one object, I need to bake 10-20 objects that use same materials but they are different objects. Because other way I'm obligated to use a proxy object to bake. Similar problems if I'm baking a lightmap ¿How we bake a lightmap? joining all objects in one? it's not practical.

So, the base of the system must be not ligated to the object. The bake must be separate "nodes" that make reference to what objects must to bake (with a list of objects, a collection or maybe materials) and made all this process automatic. And must to allow that objects will bake only with same name objects, or maybe other solution, to avoid problems baking.

Other problem of the actual system, not this patch, is that the system apply the border dilation in each bake, not at the end of the bake. It make taht the dilation can overwrite other islands pixels, depending of the baking order.

That doesn't make any sense. Yes, we should be able to bake multiple objects at once, without manually clicking bake on each, but the setup of all the baking needs to be individual per object depending on materials and UVs.

It's a good first step to improve the bake system. Anyway, I think that the main problem of the actual implementation of baking is that it is by object. It's is a error, because we don't need bake only one object, I need to bake 10-20 objects that use same materials but they are different objects. Because other way I'm obligated to use a proxy object to bake. Similar problems if I'm baking a lightmap ¿How we bake a lightmap? joining all objects in one? it's not practical.

It is not better allow a RGB8 to make faster renders? The render that user ask is not important the quality, only needs a preview.

In T69992#802283, @Campbell Barton (campbellbarton) wrote:

Those modes don't especially need this. This doesn't mean it doesn't work well, just that it's not needed in these modes.

It won't work well with paint vertex, sculpt, Uvs,... Also It have few sense, if the user wants active tools he don't need modal shortcuts. If the user uses modal shortcuts he won't need active tools. Also if the user is advanced he will know to change the shortcut of a active tool.

HAve you tried the option inside viewport->view>vierport render animation

Yes, it must be by default. Few days ago I had the bad experience of don't take this in account and that my project with good polycount was out of specs only when I export the meshes...

Tested last build of 2.81 beta in webpage, it's not solved.

After some work I have seen the bugs other times and I discover that if a edit a UV, with unwrap or smart UV Project I don't see any change in the UV editor. But If I save the file and open in 2.80 the UV are edited in 2.80. So the problem appear to be that Blender don't update the UV editor.

It is that, moving between uv layers.

Could be this task change to high priority? actually any workflow that implies subdivision is nearly dead.

@Sergey Sharybin (sergey) I have two CPUs, intel i7 4790 and amd ryzen 3700x, videos recorded in the Ryzen. I can also test it in other intel i7 and a old quad core.

In T70816#796065, @Philipp Oeser (lichtwerk) wrote:

Can confirm. (wonder why this hasnt been reported before...)

T58473 might be related.

@Sergey Sharybin (sergey), @Brecht Van Lommel (brecht): would you consider this a High priority?

Side effects of the actual subdivision.

I can confirm this bug, I wanted to report few days ago.