It my first time, then i try to find bug in dependency graph, so sorry if im wrong.
As i can see, object visibility depend on object location (for make possible skip render of object, what you can't see on screen)
But your driver depend on visibility flag in drivers, that depend on object visibility flag (Object.visibility - you setting in outliner affected on drivers flags)
I took another look at this one, and I think I found the main culprit.
Maybe i refresh that idea :D We need multi cpu for any modifier like decimate, laplaciansmooth and other for clean up 3d scans :)
Hello, i not sure that can understand bug description. Can you provide more details and steps in your description?
FYI, I'm currently merging master in this patch and check if we can make the initial functionality master ready for Blender 3.5. I might strip it down a bit for that, while keeping the general API in place to allow for more complex/better implementations in the future.
Seems like precision issue in color ramp ease interpolation. I wasn't able to reproduce at first, but then I noticed the unit scale and actual absolute size of the object it way too big, so this may be limitation. But since eevee handles this well will confirm.
Although I agree, we shouldn't rely too much on callbacks and storing arbitrary data for them, I don't think RNA is the right system for that. It's not reliable, performant or flexible enough. The UI often needs very specific behavior that RNA is not designed for.
Perhaps you are chosing which symptom to ignore when you write your summary. I would alternately phrase this as:
Thanks for the clarification, the main issue has been using Blender's Eevee Renderer viewport to edit and preview specular reflection of materials such as a shiny plastic as it wouldn't render those khr specular extensions with Principled BSDF v1 in the viewport. We could only see the export gltf material node properties working in external GLTF viewers like WebGl ones. Obviously for a workflow for metal surfaces this was fine but my work's 3D team are moving to using Blender primarily for GLTF model authoring where we are hitting these issues when we just want to edit the specular reflection glossiness of materials that are not requiring metallic properties.
Thanks for the patch. However, you missed on key use-case in rna_Panel_register.
To phrase that another way — Principled BSDF v2 will be compatible with KHR_materials_specular (control of specular reflection, within a metal/rough workflow in glTF), but not compatible with KHR_materials_pbrSpecularGlossiness (outdated spec/gloss workflow in glTF).
Hello Robert,
Very nice! This is a good example of how to add a modal keymap in general-- might come in handy in the future.
there are already discussions on integrating it with geometry nodes
@kursad k (kursadk) @ronan ducluzeau (zeauro) This is noted down as an important use case for the future multires rewrite, also in relation to T101778.
Multires needs to become more accessible for other parts of Blender and there are already discussions on integrating it with geometry nodes.
But this is outside of the scope of the current projects and not a bug.
The code looks good to me.
"patching file patch" -> it's not that one patch failed to apply, it's that I miserably forgot a && in between patch commands. I've made sure to run make clean && make deps this time on a rockylinux docker image, it ran, new diff is up.
Thanks for video, I can reproduce only on Mac machine
Thanks for update. @Campbell Barton (campbellbarton) do you know why this would behave differently in wayland? I think I have HW to check, so I could test/investigate this issue.
Thanks for info. So this happens, because you have modified F2 default shortcut, which is expected behavior. So I will close this report. Thanks for reporting anyway.
Can you specify touchpad hardware or at least notebook make and model?
2.83 doesn't have asset browser, so not sure how could I test. It's possible this is issue with file browser in general, but haven't looked in depth at this
Looks great! This does fix the issue. Thanks for the patch.
@Joseph Eagar (joeedh) can you have a look at this and commit it?
Here are also various donations from the devtalk thread. Some don't have .blend files attached but can be used as direct reference for creating new matcaps.
Some are also updated versions of the current matcaps by the original authors.
Some important notes from the devtalk thread.
Some of those don't have .blend files attached so this needs to be done again from scratch.
Gotta love the visiblity of the scrollbar.
Thanks for working on this.
Nice!
Can confirm that this is indeed an issue affecting the Metal backend on AMD devices, will investigate.
remove unneeded include
Nice work, I think it's a good idea to have those operators under one hotkey. Final decision about that is for actual animators, though ;-)
The code looks good, just a little refactor to polish it.
let's wait until the discussion there is finished. still ongoing at this point
Actually there's a couple more things I'd like to see addressed:
Well, until it is removed, while it's published on the Internet at the documentation site, we have to ensure the correctness of what is produced.
Thank you bekzii!
It seems to be removed by the new hair and its physics anyway.
The diff 60199 is the same as 60196. There are no code changes at all. I just wanted to update the commit message and the description/details of the revision. I am new to Arcanist, hence the mistake.
@Germano Cavalcante (mano-wii) Also important to note: Your patch implemented this design for the 3D Viewport but not the other editors, like UV Editor and Video Sequencer. So once the patch lands we shouldn't close this design yet.
@Germano Cavalcante (mano-wii) Personally I agree with your points on the gizmo. While the use of the handles as a guide is an nice side product, there are other features that are more worthwhile to use instead.
The upside of simplifying the gizmo is a less blocking and more consistent UI.