Yes, I reckon it's the hardware that is at fault here. What's very frustrating is that, besides others loading more than eight image textures just fine, I have a graphics card that is an AMD Radeon Pro 5500M 4 GB. What's even more unusual is that I toggled off Automatic graphics switching, which means the Radeon should do the heavy lifting. The only thing I could think of is switching a setting in Blender to force the application to use the Radeon for Eevee rendering. Sadly, I haven't seen an option for that right off the bat. I could share screenshots to show you were i was looking and see if you could find something I missed.
It feels like a hardware limitation and might not be considered a bug. Can you upload the system info.txt generated from blenders help menu to make sure that this is a hardware limitation?
While a big texture sheet is a possible option for animating facial textures, especially since this is the case for video games, the problem is that I see this method as needlessly ridged. You can't exactly apply any frames to smoothly transition from a happy expression to a sad one using this method if you just have a couple of frames or so. As for the matter of adding more, customizing them for specific contexts is rather difficult along with the fact that I'll need a very large image texture just to accommodate all the frames. On top of that, adding more to the sheet provides its own sets of challenges, especially if I have to apply the right drivers to a rig control.
Sun, May 9
ahh - for animating facial sprites - you may want to look at baking to the big texture sheet like I said,
then set the uv to the bottom left image - and use 'vector math' add - object color - then you can keyframe object color using 'constant' mode and play the animation in the viewport
You mean apply all the textures onto a single image texture and manipulate the UVs and/or mapping coordinates? I'm actually familiar with this method. In fact, another workaround I have in mind is using Keymesh to swap the material slot of the faces. I'd rather not use either of those methods yet for two reasons.
a temp work around is to bake all the textures to a single large atlas - this makes things render really really fast as well.
Fri, May 7
So since it would not be considered a bug atm. and is already covered by a design task, there is no need to have this open separately.
No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.
Thu, May 6
Adding tags to match the original bug.
@Dalai Felinto (dfelinto) If I could, I would
vote for commit D10215: Fix T83398: Fade inactive geometry overlay option not visible depending on the mode to be in 2.93.
Wed, May 5
Not sure why but the crash seems to happen randomly with an unhandled exception thrown inside colormanagement.c
Haven't checked the attached file, but I can confirm that Blender crashes randomly with the default startup
Tue, May 4
This is still an issue in 2.93 beta. Even the slightest bit of transparency and the mask/face set disappears.
I used it a bit more and the issue I had before is basically gone. The only performance related issue I notice is when switching between objects that take a long time, the overlay will be significantly shorter. It's to the point that if the operator is used and it will take a couple seconds, the flash is just a very short blip.
Can this be improved so the overlay animation only starts once the transfer mode operate is done and Blender is no longer frozen so that the flash animation can run whole?
Mon, May 3
It's been 3 years since this task was created - surely most of the community is eager to see some action!
Is there any pre-production that can be done with our hands to help push this forward?
UI designs, sketches, workflow examples, anything you need to start the discussion on what the new system will and won't be at least?
If it breaks for users that disabled Windows Ink I guess it's not as bad, they may be able to guess that they need to change the Blender or system configuration to get things working. I don't Windows Ink will work well for 99% of users out of the box, give the amount of issues that can be found online in various popular apps, and often with advice to disable Windows Ink to get things working.
@Philipp Oeser (lichtwerk) Thanks for looking into it! For now I worked around the issue by fully recreating the object using geometry nodes to transfer the geometry data.
Sun, May 2
Sat, May 1
Thu, Apr 29
@Ankit Meel (ankitm)
now I can`t reproduce it. n-gone goes away after first remesh (even if volume preserve is active).
So I'll close it as resolved.
Please add redoable steps that created the large ngon
Wed, Apr 28
- Fix formatting
- Review update
Would use it at overlay_mode_transfer and use mode transfer everywhere in DNA/RNA and operators. This way search in all files would give you a good indication how it works. As the overlay is in drawing code this is already an indication that it isn't selecting.
I think it would be preferable to expose face sets as a builtin attribute (we have been talking recently about exposing the builtin attribute to python). I guess maybe that doesn't mean we wouldn't want to expose them here, but maybe it's redundant.
Transforming in sculpt mode works by applying the same transformation that is happening to the sculpt pivot (a internal point were the transform gizmo snaps by default) to all the vertices in the sculpt + mirror operations. If you change the pivot origin, you are not scaling the vertices form that pivot, but scaling the sculpt pivot from the 3D cursor and the copying the transformation to the vertices. That is why it looks like it is moving.
Tue, Apr 27
Yes, face sets for read only should be fine.
Better check with @Campbell Barton (campbellbarton) for the Python API changes.
Face sets, mask and visibility info from the sculpt can't be exposed directly to python (or to other areas of Blender) for editing operations. After editing that data, some internal updates need to happen to keep the state of all visibility flags on the mesh and PBVH in sync.