After sharing this [[ https://devtalk.blender.org/t/bad-dependencies-between-viewport-render-and-actual-memory-consumption-in-headleass-background-mode/24537 | post ]]linking to our conversation

More uncertainty in another task:

In T66950#724102, @Germano Cavalcante (mano-wii) wrote:

... but I don't understand what the Bone selection overlay really intends to do.
(Apparently it populates objects of the MESH type as well).

So apparently this is more or less expected?

Will add Animation & Rigging since this indeed only seems to be a problem with posemode.
(not even sure about the special meaning XRay seems to have in posemode? Need to check, but when you have XRay on generally, then switch to posemode, this is first OFF, you can then enable it "again"?)

Can confirm.

The Filmic Blender repo has a newer LUT file, I can update to that to make it match. However I agree there is something wrong in that config as well, so it's not a full solution.

In T98405#1365439, @tempdevnova (tempdevnova) wrote:

Yes I am aware of that however even when taking the perceptional differences into consideration the value is too high:

The luminous coefficient for sRGB blue is 0.0722 if we know convert the Blue value of 40 into the percieved brightness we get: 40*0.0722=2.888
So basically the RGb triple 0/0/40 is perceptionally as bright as 2.888/2.888/2.888, which is still way to bright to be considered middle gray.

Simplified file:

I think you may have misunderstood me. What I meant to say was that originally my report was about the false color transform giving incorrect values for colored pixels, but in the course of discussion it somehow turned into a report about the Blender implementation having different values than the Github Filmic version, which I think is a completely seperate issue that should be addressed seperately.

@Jeroen Bakker (jbakker) But it is not just about tagging the icons for updates, right? Workbench doesn't seem to do preview renders at all and material icons for it are transparent and will stay that way if you don't use a render engine that support previews.

That's the reason why I did publish my tests here. Is this a real "bug", a "known issue" a "To Do" or what? I am not enough educated in this field to express a useful opinion, and thanks Troy, Zijun and Genco for having been invited to express their thoughts here. Everything can be done better and nothing is perfect in this world. If it's not a "bug" per se or a regression, this bug report should be closed, in my personal opinion. I do use extensively the False Colour to expose the shots in a production I'm currently working at, and hope I'm doing it right.

In T98366#1364419, @Jacques Lucke (JacquesLucke) wrote:

I don't think that's ideal indeed, but I guess there is still an intent to mark with float2 attributes are UV maps, or not?

Yes, that still sounds reasonable to me, but it's not very urgent to me currently, especially when we've solved the "active uv map" issue in a different way.
Such a tag would still be useful when some node does special handling for uv maps for reasons that I don't know right now.

I never thought about this. When switching the render engine the depsgraph should trigger ED_render_id_flush_update. Perhaps we should look into its logic and see if we can finetune it.

Somehow this bug report turned into something else than it was originally...

About this though, this is rather expected, as perceptually blue color with the same emission intensity would look darker than green, so the RGB to BW Transform takes that into account
Yes I am aware of that however even when taking the perceptional differences into consideration the value is too high:

Thank you very much!

I don't think this is necessary, I will tag the module and see what they think.

Thanks. I can confirm that it is fixed.

I am just saying that this memory is not only allocated for rendering, but also for other things that Blender does, so it is not entirely unreasonable that the visibility of objects in the view layer might have an effect this. I would just wait for a more informed answer on devtalk.

you dont think viewport flags should not affect background mode render ?

The memory usage at the start of the status line accounts for all allocations that Blender made, even outside of any rendering operations, so I think it is expected to see an elevated memory usage when more objects are involved in the view layer update.
I am probably not the right person to give you insights, but since this tracker is for bugs and errors, I would suggest you post this in https://devtalk.blender.org/, where you might get better insights. But arching this for now.

@Clément Foucault (fclem) Is there any way the 3.1.2 behavior could be an option as well, for both Eevee and Cycles? While I understand why someone might want box projection for mapping textures onto already displaced geometry, it's also the case that often someone might want to displace geometry and apply textures to it using the same coordinates for both too, without having to UV unwrap it. The screenshot in the original bug report of the brickwork example is a good example use case for this. And as far as I'm aware of, there's currently no way of achieving this right now in Eevee or Cycles, without having to manually UV unwrap a mesh. Which is an approach that's incompatible with generated geometry.

I can confirm.

System Information:
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: Intel(R) UHD Graphics 620 Intel 4.5.0 - Build 30.0.101.1660

Do aov use MRT now?

If all tools, modifiers and nodes automatically set the active UV map on creation, are there cases where this would happen and users would have to go and fix the active UV map?

Guess that depends on how the ui for creating uv maps look like. We could e.g. have a drop down in the Store Named Attribute node that allows the user to pick "uv map", and then the default uv map would be set on the mesh automatically. The same would be needed in the modifier ui or node group output ui (where it's possible to create named attributes as well). With that, I don't think users would have to manually set the default uv map in almost all cases. A special node for that might still be useful when importing external data within a node, where it's not clear what attribute is a uv map.

In T98366#1364403, @Jacques Lucke (JacquesLucke) wrote:

I think if no name is set, or the attribute does not exist, then no attribute should be used. These heuristics of where to use which attributes seem to cause us more trouble than it's worth.

Not sure who said not to copy paste from the manual, but I think the approach should be to copy from the manual as the default, and then edit where it's not suitable. Tooltips should not replace the manual, but generally I think both should be using the same terminology and explanation. With the manual potentially having a longer explanation that does not fit in the tooltip, or having a shorter explanation if there's already a description text for the whole node that explains the same. I don't think it should be an alternate explanation, but when you find a better one we can update the manual with that.

but this will require adding validation in various places that add/remove attributes, not just manually by the user but also in the modifier stack or geometry nodes.

• Storing a name seems reasonable to me, but this will require adding validation in various places that add/remove attributes, not just manually by the user but also in the modifier stack or geometry nodes.
• If no name is set, will just the first attribute with the appropriate type in the list of attributes be used? Or would it be valid for none to be active?
• Merging meshes with different active attribute names is no new problem I think, is already something users may need to handle.
• I think it makes sense to have "default" and "edit" attributes. Not sure the term "active" is needed still.