In T78495#974281, @Richard Antalik (ISS) wrote:

No difference there in my case unfortunately.

Does this happen if you collapse all other editors?

In T78495#971910, @Richard Antalik (ISS) wrote:

I am testing on windows, and I can not feel any difference.

! In T78495#971272, @Ludvik Koutny (rawalanche) wrote:
I suggest you try to launch both at once, and place the windows next to each other like on the video. It's easier to feel/stop if you can switch between them rapidly and compare immediately.

That is exactly what I did

Does this happen when you hold down ctrl + middle mouse button and move mouse up and down in shader editor?

To be sure we compare same scenario as you report, please specify what software you used to record video at what settings, and upload example .blend file with ideally visibly bad performance.

In T78495#971137, @Richard Antalik (ISS) wrote:

I can not reproduce this issue.

Does this happen with default file and when you click on File > Defaults > Load Factory Settings?

In T78350#968974, @Philipp Oeser (lichtwerk) wrote:

Just to make sure we are all on the same page (and save devs a bit of time setting this up):

Could you share your example .blend file?

In T78349#970379, @Alaska (Alaska) wrote:

In T78349#967995, @Ludvik Koutny (rawalanche) wrote:

Are you sure reducing rendering performance to 20-30% by enabling denoising on relatively modern hardware is not an issue?

Sorry for the late response. The performance drop caused by the denoiser would have to be reviewed by a developer and they could make a better judgement than I can on whether or not this is considered a bug. However, this performance drop makes sense to me as for every sample (for the first few samples), denoising needs to be run. Denoising takes time as and a result you get a slow viewport render performance.

OIDN is also indirectly called the "slow" denoiser by the fact that the OptiX denoiser is called "Fastest".

In theory, speed in improvements can be had by, like you said making the denoising only occur every 5th sample or by doing denoising a-synchronously. However, these are requests to a change in behavior or a request for improved performance which are not to take place on this site. For feedback and feature requests, make the report here: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

A 20-30% drop in performance would be considered a "bug" of sorts if the performance drop is caused by a update to Blender. However, the performance drop in this case comes from the enabling of a feature that is known to reduce performance.

I would open this report again so the developers can have another look at it, but sadly reports closed then re-opened usually aren't reviewed in a timely manner. If you believe this is a bug, feel free to open a new report.

I may be mis-reading some of the stuff you've said. I've been having a few issues with that over the last few days. Sorry if I closed your report on the basis of something I didn't interpret properly.

In T78349#967954, @Alaska (Alaska) wrote:

Thanks for the report. While we do continue to work on improving performance in general, potential performance improvements are not handled as bug reports.

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

For deeper design changes about the workflow, how to set up bake passes, we should not add temporary intermediate solutions. In that case it's better for users to use a more complete add-on anyway.

I would not be surprised if this was still ignored as a target for 2.90 even despite overwhelming amount of discussion both here and on devtalk thread, as well as significant ease of implementation (it's a minor feature).

I'd consider this a feature, not a bug. The pixel size feature is used to subsample viewport result which is useful to boost interactivity and viewport rendering speed on high DPI monitors, where the 1x resolution scale can be too dense for preview purpose, requiring too many resources to have reasonable rendering performance. Up until recently, the pixel size subsampling was useless because it used nearest neighbor (pixel perfect) image scaling. Now it seems to use bilinear, which is much better as it makes this feature actually useful with high DPI monitors without introducing ugly aliasing artifacts.

In T73479#939451, @Chris Kohl (ckohl_art) wrote:

In T73479#939276, @Ludvik Koutny (rawalanche) wrote:

1. Blender is only 3D DCC which has the concept of face dots. All the other DCCs don't have it

How many times must I correct you before you stop repeating this lie?

https://i.imgur.com/zkARZ5U.png
(That's Maya, in case it wasn't obvious.)

By all means, I encourage you to be an advocate for decoupling face dots from shading modes as much as you wish, I agree that people should not be forced to use face dots, but they also should not be forced to use face area. Face dot selection should be set independently from shading. All 3 things should be set independently from one-another: Select-through, shading, and face dots.

Kindly don't spread lies and advocate for the complete removal of a useful selection feature. You do not speak for everyone and your own personal workflow is not everyone's workflow.

And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.

In T73479#938574, @Paul Kotelevets (1D_Inc) wrote:

In T73479#938431, @slowburn (slowburn) wrote:

I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.

Facedots are already disabled by default in solid mode, so there is no more corellation between facedots display and face mode anymore.
It is also done by developers.

Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings.

Snaps or proportional editing have nothing to do with selection.
I think placement near Xray button from our proposal is better since shading influences selection as well.

Listing all binary combinations wouldn't show anything else that's important.

Either you or the developers will have to do this.
This can expose situations like that

Shading	faces selection type	selection mode	default overlays	option	Solid checkbox	result
solid	?	through	facedots off	on	on	?

Should a solid checkbox be unavilable in some cases?

Also row 3 is highly questionable... That makes you need to precisely select faces by facedots centers that you don’t even see

Facedot positions can also be predictable. For example in this cylinder:
And someone might find it useful in some rare corner case.

Indeed, a very rare case.
All such cases are very specific, are much faster to perform from wireframe shading mode (rather than setup selection back and forth), disallow to read through mode from model appearance and requires separate option.
It looks like LSTV mode but without ability to see backfacing.
Not sure if it's worth it.

I don't think people would have much difficulty to remember which checkbox they have clicked.

For sure, unless they have no other business, rather than keeping it in memory.

But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:

So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.

That's interesting solution, it will make mode visually clear.
The same way behaves wireframe and Xray buttons (there was an idea to make them independent, since wireframe without xray is more about visual style rather than regular shading mode).
But, as it was told before, such modes are not mutually exclusive.
For example, what is the difference between this possible options combinations? I can see only two unique results.

But then backfaces can get unintentionally selected and there's no way to prevent that in Blender.

Not sure I understood that correctly, can you give an example? How you can get unintentionally selected what you can see?

In T73479#938454, @Vyacheslav (hitrpr) wrote:

Also I can`t figure out, why box select is default for tweak tool for all objects.

Yes, after selection goes some operation, so you have to switch to anything but box selection immediately after the very first selection anyway.

So I prefer to have global tweak tool mode at least.
Or at least full syncronization per object type and per editor type.

Tweak also allow to perform picking selection type, and it is the most common operation, that follows selection, so I agree that it could be a nice default.

In T73479#932334, @slowburn (slowburn) wrote:

I'd also add that the select through should only modify box/lasso/circle selection, but the single click selection should remain at the behavior of current occluded selection. So that single-clicking things like vertices or edges does not accidentally select elements on the back of the mesh. Select through without Xray should really only affect box/lasso/circle area selection modes.

In T73479#919725, @Paul Kotelevets (1D_Inc) wrote:

In T73479#919446, @Ludvik Koutny (rawalanche) wrote:

just having to wrangle xray mode on and off

We also feel such discomfort from lots of "again" behavior from things that was added or removed recently.
You also assigned Burninate token to this design task, please, be careful with that.

There's very concerning lack of progress on this. I have again wasted hours and hours of time past two weeks just having to wrangle xray mode on and off again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again...

In T73479#913930, @William Reynish (billreynish) wrote:

What many (all?) of these ideas, mockups and suggested solutions don't address is that this is much more fundamental than just being about how X-ray works.

The basic paradigm in Blender is that you can select what you see. So, in Wireframe view, you can select any wire you click on, also on backfaces.

Blender could work differently, but most of the suggestions here conflict with the concept of you can select what you see. So the issue is not out of spite or anything like that, but because of this inherent conflict between two incompatible paradigms.

The only solution I can think of to address this conflict is a setting in Preferences called Decouple Selection from Visibility. Once this is set, we could show tool settings to Select Through or not.

This could address the conflict, but it would then be something users would have to enable in Preferences, and tools would have to check for this preference before showing the tool setting.

In T73479#913999, @Paul Kotelevets (1D_Inc) wrote:

The problem is that facedots are used not only for direct access, but also for analysing topology structure.
Thats why Blender is that good for fixing messy imported meshes at industry level - it allow you to see the topological issues directly. That's one of the points of the facedots.
Here is a brief example of topology problems that facedots reveals, but it is a secret, please don't tell anyone.

In T73479#913853, @Paul Kotelevets (1D_Inc) wrote:

I was looking through possible solution realizations for paragraph C, like that one.

It is interesting approach - to create special subset of selecting tools, but they refers to Xray (because it is an addon, and have limitations), that makes through selection result different from regular one.
So I thought about combinations of cases to satisfy, to provide the ability to check possible solutions for compliance.
I applied my proposal of the checkbox state invertion in this table, to make it enabling faces area selection, and got such a table.
Every row represents available selection mode, so there are 5 of them.

	Display mode	faces selection type	selection mode	default overlays	checkbox	Result
1	xray	facedot	through	any	off	Xray with facedots selection
2	xray	area	through	any	on	Xray with area selection and no facedots
3	shaded	area	occlude	facedots off	off	Shaded with occluded area selection and no facedots
4	shaded	facedot	occlude	facedots on	off	Shaded with occluded facedots selection
5	shaded	area	through	any	on	Shaded with through area selection and no facedots

This way, a checkbox, proposed by @Ludvig Nygren (ludvignygren), will override overlays to perform area faces selection for every type of selection tool.
Is everything complete?

In T73479#911565, @Paul Kotelevets (1D_Inc) wrote:

In T73479#911076, @Ludvik Koutny (rawalanche) wrote:

I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through.

No, wrong.
According to summarizing post, this topic is about solving two problems:
View Selection Occlusion/select through problem and Face boundary selection.
I was confused because you called "Face boundary select" checkbox as "Select through" for some reason.

I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago...
I basically always want backface selection enabled on a fully opaque mesh with no face centers.

Well, such inconsistency took it's place because it was assumed that Xray can replace LSTV mode because of... some reason.
So it is one of that pretty much fresh inconsistencies that was brought since 2.8.
For sure, you will need to reproduce Maya behavior since current solution is not good even by Blender standards, and also because Maya approach fits most of workflows that can be performed in Maya.
Attempts have already been made to remove the Facedots concept from Blender by developers about a year ago, for some reason, before even asking what they are actually needed for,
maybe because there are some people which type of work they perform allow them to not to use facedots, like Maya or Max users.
However, they were moved back because face edit mode is for faces editing, and facedots provides the ability of some workflows, difficult to reproduce in Maya or 3dsMax, because of lack of facedots there.
Such problems arise because instead of designing a process with investigating and studying a proper range of workflows behind tools, some assumption is made during development, which is forced until it becomes critical.
Workflow design matter is pretty much fragile - there are a lot of things that possible, but not so much that are versatile, and it is incredibly hard to find the best combination that is almost perfect for every possible use case - a bit wrong assumption, and you've got inconsistency like that, ruining usability experience for some workflows.

In T73479#911051, @Paul Kotelevets (1D_Inc) wrote:

In T73479#911001, @Ludvik Koutny (rawalanche) wrote:

These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.

Not entirely sure how this should work. In short:
When button is pressed, but checkbox is not filled, it will display Xray, but will not perform select through,
and when button is pressed and checkbox is filled, it will display no Xray, but will perform select through,
both for object and edit modes?

I don't know. Most of the apps I've checked here do have checkboxes maybe a bit closer, but not anywhere near as crammed together as Mac OS, such as:
VSCode:

I have posted this mockup to death already but I am going to post it here as well because it simply solves all the questions asked above. It's just that someone still keeps artificially making this a problem:

In T74967#902314, @Jean Da Costa (jeacom256) wrote:

@William Reynish (billreynish) please I just want to know.

Will there be a way to individually apply a modifier just like the current stack system?

And I need to know how is the addon compatibility is going to work. Most add-ons rely on a linear stack to work.

In T75245#901896, @Germano Cavalcante (mano-wii) wrote:

After rereading, I think I understood the problem.
If I understand correctly, while the UV Map indicated is A, the UV Map of the other selected objects are B and C respectively and the expect is the others objects to be A too.
If this is the case, it is not a bug.
What should happen if the UV Map for each object is {A, B, C}, {D, E, F} and {G, H, I} respectively?
In this case, it doesn’t matter which name appears in the UV editor, it will never refer to all objects.
And what if a user wants to edit the UV A of one object along with the UV B of the other?

This could certainly be better, but it works as designed and as you can see, the solution is not as simple as it looks.
A plan is needed to rethink the interface and resolve all cases.

For user requests and feedback, other channels are more appropriate: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

In T75245#901618, @Germano Cavalcante (mano-wii) wrote:

I cannot reproduce the problem.
Here it works normally.
Are you sure you are not confusing the UV of different objects? (since they have the same name)
GIF:

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:

I am convinced that for the most common cases, users having to set up both baking nodes and shading nodes is neither required nor simple enough. The choice is not a binary one between what we have now and a workflow aimed at more technical users. If there are use cases we don't cover or someone prefers a very different workflow, add-ons are still possible.

I still have not seen it explained which important problems baking nodes solve, that can't be solved otherwise. The ability pack multiple maps into color channels is important, but is possible to implement with a simple setting per baking channel. Being able to write to disk instead of memory is also something that could be an option or just default behavior, independent of using nodes or not.

I think it's easy to underestimate the value of having a system where it is explicitly defined what the baking feeds into. If Blender knows that roughness will be packed in channel X, users don't have to manually set up shading nodes extract it from that channel. If we know that simulation X depends on texture Y being baked for particle emission, or an exporter can verify if all baked textures are up to date, that helps automation and validation.

Systems that more loosely couple things together where users have to manually ensure that this filename or setting in one place matches this other thing in another place are the source of many problems in production in my experience, and we should try hard to avoid that.

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.

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

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

Yes, it does, and many people are not happy about that, because you then end up with multiple overlapping UVs channels on one object and you then have to do ugly workarounds of combining separate textures afterwards into one image using some clumsy image combiner tool they've built in to mitigate that. That's why most of the people I know always export the object with only one material ID and material selection masks.

Ok, so it's not actually object based in Substance Painter, but in your workflow you try to make it behave as such.

It's just all around inferior workflow. In game engines, you want to minimize the amount of material IDs on single object as each material ID adds another mesh draw call. 6 material IDs and suddenly you end up with 6 draw calls instead of one. So the common workflow is having one texture per object, not one texture per material.

Separating multiple materials into multiple texture sets using multiple UV channels on a single object just doesn't make sense, from both complexity and performance standpoints.

Right, but this is possible in my design. You would be able to have 6 materials with their own shader node setups, and then 1 baking material that bakes the result of all those materials into one set of textures.

And then baking material could be used for previewing the bake in the viewport and exporting.

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

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

Then what would happen if you had same material applied to multiple objects with parts of these multiple objects overlapping same UV space?

You'd link a different baking material to each, with different images.

All of the most successful texture authoring/baking tools out there such as Substance Painter have object based baking.

Are you sure about that?

Doesn't Substance painter create one Texture Set per imported material, and then have baking settings stored in that Texture Set?

https://docs.substance3d.com/spdoc/texture-set-154140919.html
https://docs.substance3d.com/spdoc/baking-109608997.html

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

There's another aspect to be considered here I think, which is how you can easily preview or use baked textures. This may be to check for quality before exporting to a game engine, or because you're using baking as a way to speed up rendering with Cycles or Eevee. I'd like to avoid having too much of a disconnect between the settings for baking and using textures.

This is especially important for exporters. When exporting to glTF, USD or another interchange format, you not only need to know what the baked textures for an object are, but also how to use them in the exported shader.

There are many places we could store baking settings:

• On every object, but make editing many possible with presets and multi-object properties editing
• In a new type of datablock with baking settings
• In material datablocks
• In image datablocks
• In collections for all objects contained within

I'm thinking that maybe material datablocks and shader nodes are the right place?

Materials Datablocks

Materials would store a few settings that are common to all bake passes that you would bake together. Particularly cage objects and related settings.

There would be a new Bake Texture shader node. This would be like an Image Texture node, with an image datablock. Renderers would simply render it as an Image Texture. For baking it would have the bake pass and associated settings. There would be some restrictions, maybe directly specifying a UV map rather than a Vector input for textures, only Flat mapping, etc, whatever is needed to make it efficiently bakeable.

For the simple use case when you just use a single material as input for baking, you could put all baking related settings in the same material.

This design would support baking multiple objects with multiple materials into a single texture too. You would link the "baking material" to all objects that you want to bake together, and all other materials would be baked into that. Making a clear UI for this might be a bit tricky but I think something can be figured out.

Some ideas to improve on this beyond an initial implementation:

• Besides a bake pass name, Bake Texture nodes could also support an input socket. If unbaked it would pass through, if baked it would read from the baked image texture. This would avoid having to create multiple BSDF nodes, you could just insert nodes in an existing shader node setup where needed.
• Bake Texture nodes could have an optimization where if it detects the input is constant across all materials used for baking, it outputs a fixed parameter rather than an image. Or there may be a better solution to this, but it would be great if users wouldn't have to think about this aspect somehow.
• Ideally it would be possible to create a shader node group matching a material for the target game engine, which specifies both how to bake it and how to preview it in Blender. With additional Python scripting it could automatically create image datablocks with particular naming conventions.
• Materials or individual Bake Texture nodes could have a state indicating if they are "Baked" or not. This could be used to determine what to display in the viewport, the baked or unbaked results. As you bake it would automatically display the results, or revert back to the unbaked state after clearing.
• This "Baked" state could also make it easier to ensure you have baked everything before exporting. You could select all objects, press bake, and it would only bake what is not ready yet. Exporters could check this state and show warnings or offer to bake before exporting.

For the implementation, Bake Texture nodes could perhaps be handled fully on the Blender side with the renderers unaware. Blender already performs some shader graph modification, and turning Bake Texture nodes into Image Texture nodes or fixed parameter nodes should work.

In T74967#896603, @wueo (mushroomeo) wrote:

hi i just wanted to beg you to keep it as SIMPLE AS POSSIBLE. and not to reinvent wheel...

that means keep all the names as it is right now, in modifiers like object as OBJECT to choose and vertex groups too, or you want to rename current modifier options too then?

then why not keep OBJECT word instead MESH in nodes? because can get rid of vertex group in modifier nodes? why? it just makes unnecessary complex.
why not keep the vertex groups inside nodes ? it would make it just simpler, you sure can have seperate own nodes for vertex group but most people will still want just to connect multiple modifiers in node window just for reason to have much more clear view and same time would erase chaos of to much nodes and speed....

it would keep blender understandable consistent, like MESH is in edit mode and have tools named for it like vertex, edge, face, etc...
for selection mode node of vertex, edge, face i suggest just use simple naming: MESH SELECTION MODES. this way everyone could understand it immediatly and not get confused.

and same for own vertex group node, and collection. we had already change of groups to collection : (

i suggest best example just keep make it as sorcar addon nodes... its simple , fast , easy, even it could be made even with fewer nodes too...

https://duckduckgo.com/?q=albert+einstein+simplicity+quote&t=ffsb&atb=v1-1&iar=images&iax=images&ia=images XD

In T74967#896402, @William Reynish (billreynish) wrote:

@Asher (ThatAsherGuy) It's not two node types - Clusters are analogous to selections. Some apps call them Groups, though it might be confusing since in Blender, the term 'group node' means something else and very different from selections. The apps that call it 'Groups' use a different term for group nodes like 'networks', 'subnetworks' or 'assets'.

Some apps call it Clusters, which doesn't bring with it the naming collision with the over-used term 'group' in Blender.

But, we could also call it simply 'Selections' - although I think users might expect that it would then relate to the current selection in the viewport, which could be misleading.

Or we could call it Groups, but then rename group nodes to 'Meta Nodes' perhaps, which would be consistent with Meta Strips. I don't mind too much what the name is, as long as it doesn't cause confusion by calling two very different things the same name, and as long as it is reasonably clear what it means.

Blender's Vertex Groups perhaps should be renamed to Weight Groups, since they don't really store selections, don't allow for edge or face data - instead they allow you to specify a weight value per vertex.

Generating node graph automatically while editing would only make sense if it was opt in and off by default, as otherwise unsuspecting users working destructively could end up generating very long, live, complex chain of procedural operators which would degrade the performance linearly with the amount of operations. I am very much looking forward to procedural modeling, but direct destructive modeling still shouldn't go away completely.

In T74718#890775, @Germano Cavalcante (mano-wii) wrote:

I don't think I'm wrong. The description does exactly what it says. Moves the view (modifying the viewport view angle and location) to make the selected objects visible within the viewport's boundaries (ie frame the selected objects).
So I don't consider this a mistake. Even less a bug. But a request for improvement.

Closing as this bug tracker is only for bugs and errors.

For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests
For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

In T74683#889996, @Philipp Oeser (lichtwerk) wrote:

You can select muliple files in order to have this turn to an Image Sequence in the node.
If this is the case (a sequence - valid naming scheme - is selected and you have the Detect Sequences option turned on), the Image Texture node will switch from Single Image to Image Sequence.

Dont think it would be a good solution to create multiple Image Texture nodes when browsing for images in a single Image Texture node.

One thing that could be improved is that you cannot select multiple files if Detect Sequences is turned OFF (this would not be considered a bug though).

A workaround for quickly creating multiple Image Texture nodes is with the Node Wrangler Addon (this then has ⇧+A > Texture > Multiple Images).

That all being said, will close as not-a-bug (feel free to comment though if you still think this is a bug...)

In T74610#888448, @Robert Guetzkow (rjg) wrote:

@Ludvik Koutny (rawalanche) Setting the color space to Non-Color will accomplish that and I've tested that this setting isn't changed by saving the image.

In T74610#888414, @Robert Guetzkow (rjg) wrote:

I removed my last comment, because it was incorrect. The image data-block references the file. Therefore the selected color space should match the data stored in the image.

This is causing lots of damage to me on daily basis as a simple update of normal map file path (swapping to never verions) automatically reverts normal map from non-color data to sRGB. This caused lots of wasted money and render farm time since a few of the fellow artists did not notice. You can not just keep changing the color space to a wrong, image format container based assumption every single time user touches Image Texture node. Image formats such as JPG or PNG do not define if the contained data is supposed to be used with or without sRGB. If that was the case then it would be pointless to have the Color Space UI element in the first place. Now that we have it, it's just causing issues all the time, as it keeps reverting to wrong value. And it happens more often than not since pretty much all the image maps except color/albedo textures are generally supposed to be linear, not sRGB corrected.

In T74284#882173, @Philipp Oeser (lichtwerk) wrote:

This is the same as T70688, T69244, T66985, T68047, but was not considered a bug.

This changed in rB7ad802cf3ae5: Cycles/Eevee: unified and improved texture image color space handling.

Opening a new image from the Image Texture node will trigger automatic colorspace detection.
As a workaround, you can load another image from the sidebar in the Shader Editor or the Image Editor (or python), doing it from there will not trigger this detection.

This has pros and cons, but it is working as intended and not a bug.
Will have to close, thx for the report anyways!

In T55377#865263, @Sybren A. Stüvel (sybren) wrote:

Although I agree that interoperability is a good thing, I don't think this is considered a bug in Blender, but rather a known limitation of its current design.

If it is decided that it's important to adhere to a standard naming scheme for OpenVDB channels, this naming scheme should first be documented, including a list of other software that adheres to it. That will give a better foundation for such changes.

Note that I'm intentionally ignoring part of the bug report here. If a report is about X, and later changed to also cover Y, that only causes confusion. If there is still a bug in Blender, please write a new report that only covers the bug. A guideline for making a good bug report can be found at https://wiki.blender.org/wiki/Process/Bug_Reports

In T56939#869254, @Richard Antalik (ISS) wrote:

I have re-triaged this report and can not reproduce it.
Rendered mode in viewport used 100% CPU. Perhaps it is slower. but whole UI is slower.

Can you please check if this is still an issue in latest build?
https://builder.blender.org/download/

In T63356#803594, @Campbell Barton (campbellbarton) wrote:

This uses existing batches to lines to account for faces being side-on, points to account for edges being viewed side-on.

While I don't like this at all since it's drawing 3x times, it does resolve the issue without using extra GPU memory to store edge/vertex batches.

diff --git a/source/blender/draw/engines/basic/basic_engine.c b/source/blender/draw/engines/basic/basic_engine.c
index 0dd1a4fd686..feaef731d38 100644
--- a/source/blender/draw/engines/basic/basic_engine.c
+++ b/source/blender/draw/engines/basic/basic_engine.c
@@ -189,8 +189,26 @@ static void basic_draw_scene(void *vedata)
 {
   BASIC_PassList *psl = ((BASIC_Data *)vedata)->psl;
 
-  DRW_draw_pass(psl->depth_pass);
-  DRW_draw_pass(psl->depth_pass_cull);
+  /* Until we have conservative rasterization, this is a hack but it works. */
+  if (DRW_state_is_select()) {
+    glPolygonMode(GL_FRONT_AND_BACK, GL_POINT);
+    DRW_draw_pass(psl->depth_pass);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
+    DRW_draw_pass(psl->depth_pass);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
+    DRW_draw_pass(psl->depth_pass);
+
+    glPolygonMode(GL_FRONT_AND_BACK, GL_POINT);
+    DRW_draw_pass(psl->depth_pass_cull);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
+    DRW_draw_pass(psl->depth_pass_cull);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
+    DRW_draw_pass(psl->depth_pass_cull);
+  }
+  else {
+    DRW_draw_pass(psl->depth_pass);
+    DRW_draw_pass(psl->depth_pass_cull);
+  }
 }
 
 static void basic_engine_free(void)

---

Edit: testing this with high poly scenes and it can be ~80x slower, so it's not practical to use.

In D6639#156313, @Campbell Barton (campbellbarton) wrote:

Rather not have this patch in it's current form.

This patch makes rotation snapping a 4th way to set the view axis, we already have:

• Numpad
• Tilda Key
• Alt-MMB Drag

This patch is closest to matching Alt-MMB drag which is quicker to access then having to hold and rotate, if all you want to do is switch the view axis.

Further, this patch removes the ability to quickly view an object at a 45degree angle.

---

Having said this, we could make changes to the current behavior to use auto-perspective for axis aligned views (if the auto-perspective preference is enabled).

With this change it's easy to set axis views, there are some non-axis aligned snapping inbetween, but I don't think this is such a problem, since having 45 degree snapping points wont be confused with axis aligned views.

A little like how 15 degree increments for rotation doesn't make it hard to rotate 90 degrees when transforming.

Toolbar version of the Loop Cut is still broken (mouse wheel does not change amount of cuts and the highlight line is thick and aliased compared to hotkey version of the tool where the line is thin an has antialiasing.

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?

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.

In T70639#792863, @Germano Cavalcante (mano-wii) wrote:

This seems like it belongs in the paper cut thread and not the bug tracker:
https://devtalk.blender.org/c/user-feedback/paper-cuts

For suggestions on how to improve the UI, please use other channels:
https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

In T70473#788551, @Brecht Van Lommel (brecht) wrote:

This is only for the playhead and preview range, not the render output range.

Allow Negative Frame
Playhead can be set to negative frames with mouse or keyboard. When using Use Preview Range, this also allows playback.

https://docs.blender.org/manual/en/dev/editors/preferences/animation.html#timeline

In T69132#787599, @Paul Kotelevets (1D_Inc) wrote:

In T69132#787508, @Ludvik Koutny (rawalanche) wrote:

I've already above shown you many cases where origin to cursor just does not work.
Here's a typical example of something that was very difficult.

Well, cube is never a prectical example.
In practice, imported parts may have origins in kilometers far away from the model, so first you need to find them somewhere.
It is a question of relevance.

Statement: If the operation, which is used in practice several times a day, can be performed a couple of seconds faster, you save just several seconds per day.

We easily handle that case, avoiding the need to search for the origin throughout the scene, being concentrated on the model.

A nice example! Something else?

In T69132#787359, @Paul Kotelevets (1D_Inc) wrote:

In T69132#786931, @Ludvik Koutny (rawalanche) wrote:

As long as the tools you use are not being removed, why do you care?

Because it can be a way more useful than it is now)
We perform a wide range of workflows, and don't even feeling need in it's current realization. It definitely have a potential, but it is hard to call it an "enhancement" yet.

I kinda get that though, if in a few years, you are one of the last few people utilizing 3D cursor to do stuff, then it will be a candidate for removal, so then it probably will hit you eventually...

Well, as it was predicted, to that time transform tool will have translate/transform abilities,
better snap, than Blender ever had, including apparent and projections,
separate GUI with parameters, menus and functions,
addititional modes, incliding 3-point aligning, superior instances support,
and it's own addon's base, including aligning tools in a "collapse top left" way.

And most of this just to replace "Shift+S - origin to cursor" action.
That can be, actually, funny =)

In T69132#786869, @Paul Kotelevets (1D_Inc) wrote:

That means, that they want to "get rid" of using 3dcursor-origin operations from their workflow.

Is there any reason the gizmo doesn't have planar and 3D transform handles? I can imagine many cases where I'd like to snap cursor onto something on 2D plane or in 3D. Right now, with the ability to only move cursor one axis at the time, that would be an unnecessary amount of steps.

Yes, I agree here. Correcting normals for negative scale is great, because it allows you to make more unique variations of assets with instancing by just mirroring them, and still get usable normals required for example for normals maps or refraction. When you have *any* asset which you plan to use with substance painter, or anywhere else really, just make sure to apply transforms first before exporting. That's always the best practice.

In T62971#776278, @William Reynish (billreynish) wrote:

In T62971#776266, @Ludvik Koutny (rawalanche) wrote:

In T62971#775904, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I always switch to ICK when testing 2.81, so I assume that industry standard in that case would be backspace :)

No, on Windows it is Alt-Up and on Mac it is Cmd-Up, for going to the parent folder.

I've enabled Cmd-up now for Mac users, so both will feel at home now.

In T62971#775904, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.