In T54314#1407769, @Philipp Oeser (lichtwerk) wrote:

Soo, we now have:

• [1] compositor updating correctly when setting the active viewer from python (no need to manually click or use the workarounds using switch nodes anymore)

Wait. I've just started porting my workflow to finally use the new feature of Blender 3.3.0, and apparently it does NOT work from Python scripts! Changing the switches or activating different Viewers still does not trigger Compositor refresh.

I did a cache update on nodeAttachNode.
I still don't fully understand what exactly is intercepting the flag change, but it works.
I'm not sure how to deal with the RNA part.

Thanks for your report on this.

I can confirm this with yesterday's debug build. But today I don't have it. But after that, when canceled, there is still a fall. I'm downloading a newer version just to be sure.

It's not a mistake. The problem is converting to a boolean mask. It considers it highlighted even at a very low value. Since the brush does not fill all 1.0 100% of the time, after inversion it is also not 0.0 everywhere. And as a consequence, the boolean type highlights it. You can either raise the entry threshold, as I range nodes, or not use a boolean type.

Needs work to update when editing frame nodes.

In T54314#1425971, @Derek Barker (lordodin) wrote:

I wouldn't even consider your solution as a solution to the actual problem. This was a workaround in the first place to get pixel data from renders. Now the workaround kind of works if you don't render headless which seems a bit pointless. The actual solution is to let users access rendered pixels. Not viewer pixels, clearly there is a lot of us trying to do this.

Think I got a fix

I wouldn't even consider your solution as a solution to the actual problem. This was a workaround in the first place to get pixel data from renders. Now the workaround kind of works if you don't render headless which seems a bit pointless. The actual solution is to let users access rendered pixels. Not viewer pixels, clearly there is a lot of us trying to do this.

@Omar Emara (OmarSquircleArt) Thanks for the fix.

• Use the simplest attribute lookup method.
• Only store non-null GeometrySet entries in DupliObject and reduce the stack to 4 entries to save memory. I think this should be ok for now, given that meaningless entries are omitted.

There's no Cycles code remaining now so nothing really for me to review.

Rebased and simplified the code more.

• Figured out how to simplify code by using standard type conversions.

• Reorder geonode attribute lookup after particle system.

I get the crash constantly here:

@Manuel Grad (manitwo) Thanks for reporting this.

This sample file does not open on version 2.93

@kursad k (kursadk) Will take care of that later today.

Coming here from https://developer.blender.org/T99197 . Note that vertex groups are used in Blender for far more than modifiers; one example would be as targets of constraints. Attributes may have improved flexibility over VGs at some point down the line, but for the near future, the rest of Blender isn't built around them, which severely limits what can be done with meshes that can only use attributes. There are plenty of similar issues with GN meshes playing nicely with other features, for example trying to use a GN generated curve for follow path or spline IK. This plan seems like a very, very long path to me.

This revision will be changed to have frame tree topology cache and logged time for frame nodes. This will be implemented separately. So this patch will focus on calculating frame boundaries.

Thank you for taking the report. Incidentally, I was testing with previous versions of Blender and the problem also occurs in Blender 3.3, 3.2 and 3.1 (I don't have the other versions installed). Either way, hopefully it can be fixed. Thanks to all the people of Blender for the great work they do with the program.

Thanks, now I can reproduce the error.

I thought that it would still be more logical to parallelize the shared cache from 32 nodes, and not from 128
It's hard to judge, rather common sense