Hopefully not forgotten?

Duplicate of T86331

That build, from the asset-browser-branch, is no longer supported. Please use a recent 2.93 alpha build going forward and enable the Asset Browser in the Experimental user preferences. I can not reproduce your issue in any recent build.

A fix for this is in the works: https://developer.blender.org/D10535 (and is a duplicate of T85985)

Most likely a duplicate of T85609 which also mentions the DOF commit.

Which exact website? If it is not from the blender.org domain then it's not an official build and the problem should be reported to whoever built blender incorrectly since we cannot help here.

This is a duplicate of T84717 and it should have been fixed today. Can you try the very latest 2.92 or 2.93 build?

This should have been fixed with last week's 2.91.2 release.

There was clear feedback/preference for 3.8 in 2021 already but the continued lag relating to updating from 2.7 complicated it. 3.9 was even mentioned as a potential target for 2022.

In T85010#1099667, @Constantine Vojik (costavojik) wrote:

With my experience this bug exists not only on rendering but also viewport shading. If I switch or add a matcap, ambient occlusion or whatever I won't see a change until I cycle through shadings.

The viewport issue is noted here T84717 and has already been root caused to another checkin. It's a different issue.

Assuming the "lock" concept is eventually accepted by the team, the multi-res modifier's levels/render_levels/sculpt_levels fields and the screw modifier's steps/render_steps fields are also candidates for locking. It would be good to at least think about applying to those as well for consistency, or having a good reason not to. I'd hate to see that one RCS closed but then 1 or 2 more pop up asking for those other modifiers etc.

The mfehidk.sys driver mentioned on the blue screen belongs to the McAfee antivirus product. If that's listed each time you get a blue screen then the problem most likely is due to that set of software.

Probably a duplicate of T84717

Cool. I'm no longer seeing any obvious bad behavior. Though I'm not seeing any obvious perf changes either, good or bad, maybe it's just slightly faster. I've mostly been trying out viewport interactive performance using the 2.81 splash screen and moving objects - slightly - in the scene.

It's also not clear to me what's really expected here. The xxx Object has 2 UDIM tiles assigned to it. Blender will open and copy around those 2 UDIM tiles as necessary. There's no attempt to guess that the user only wants a subset of them just because the object UVs are only contained inside a subset of those tiles.

It's probably the limitation listed here: https://docs.blender.org/manual/en/latest/render/eevee/limitations.html#subsurface-scattering

This is a documented limitation currently: https://docs.blender.org/manual/en/dev/render/eevee/limitations.html#subsurface-scattering

Indeed this is straight CPU so Embree. I don't have access to a GPU capable device right this moment to try another configuration.

I'm no longer getting crashes on my side but I do observe that things are not updating correctly.

Related to T83896

I'm getting a crash when trying to render the 2.81 splashscreen. Happens for both the viewport and final render. Looks like ccl::PackedBVH::prim_tri_verts is uninitialized. This also occurs when using -t 1 on command line.

This issue is most likely a duplicate of T83300 which is now fixed in newer daily builds. No word on if it will make it back to the 2.91 series yet.

Duplicate of T83347

This issue is most likely a duplicate of T83300 which is now fixed in newer daily builds. No word on if it will make it back to the 2.91 series yet.

As a normal user here I love the feature. I'm much better served with a snapping angle of 11.25, 15, or 22.5 deg than the default of 5. It works better for typical rotations I'd want to snap too (1/8th of a circle, 1/4, 1/6 etc). It would allow me to see exactly where I should snap too much more quickly.

I'm on Windows here so I only see the long load once (using a 1070). Switching to rendering mode after that (and even after restarting blender) is fast for me. You will have to wait and see if someone can repro the problem on linux and/or if the particular driver install for you is at fault.

This might be the Optix kernels compiling. They should only do so once, and should be cached by the driver after. @changkun (changkun) can you confirm if you have Optix set as the rendering device in your User Preferences?

Muting has not been designed or implemented yet for Geometry nodes. See T82546

This looks a lot like T82353 - I haven't checked because the files to download are very large - due to the fact that an invisible/disabled collection is mentioned here.

Modifiers for volume objects were only added for 2.91.x, not the 2.90.x versions.

Potentially a duplicate or related to T82351

There's a chance the data was written to the file in a corrupted state already. Blender crashing may have nothing to do with it. Blender won't be touching the file during its crash. Even if the crash happened during auto-save, blender will first write to a temp file and only replace the original once completed.

Note to other triagers: Doing either of the following makes the bug go away:

• Changing the sub-d levels to 2 instead of 3
• Disabling the solidify modifier

A few things:

• You need to apply the Scale on your Cube.
• You should use the "Even Thickness" option on your Cube's solidify

On your Shutter object, change the boolean modifier to "Fast" mode instead of the new "Exact" mode. Details about this new mode here: https://wiki.blender.org/wiki/Reference/Release_Notes/2.91/Modeling#Boolean

T82072 is a duplicate of T77868

We will have to wait for @Clément Foucault (fclem) or @Jeroen Bakker (jbakker) to chime in. It's a really odd bug to say the least but I also experience this on a ubuntu 20 VM I have running on the side.

I've seen this before myself and it relates to your graphics (either driver or hardware). In the blender folder there should be a file called blender-softwaregl, try running that and report back if it works correctly.

The modifiers are only in 2.91.x onwards (in the video they are using 2.91.0 Alpha). They are not in 2.90.x

Try adjust the "Clip Start" option in your viewport there (upper right in your video) to something reasonable like 0.01 m

Duplicate of T80974

Most likely a duplicate of T80005

It would be great if the UI team would come together and make the call to not disable panels in situations like this. This isn't the only place where things completely go missing if you have an option checked somewhere else in the UI. IMO it would be better to have the Panel grayed out instead instead of completely removed from the layout in many of these situations. Going further, having a small text message within the grayed panel explain why the panel is disabled could be bonus points but not strictly necessary.

Oh found this bug... hate to comment after it's closed, but KDE's taskbar also shows Blender using audio continuously. It's not a good look.

Ubuntu 20.04 works fine here when using the cifs variant of SMB, e.g //xxxx.file.core.windows.net/scratch on /mnt/scratch type cifs

You have a very high level 6 subdivision modifier enabled right there. Your 419 face icing object becomes 1,716,224 faces at level 6 (even more so since the solidify modifier is also adding more faces).

The version information above says "Unknown", this typically happens after building blender yourself. Is that what you did? If you did build yourself, can you confirm you built with Open subdiv support in your cmake settings?

Hmm, I'm not sure I follow completely. How would you implement the issue described in the original part of the report where I want to enable circle select only while I'm holding down the C key. Or are you saying that such a thing cannot be done within an addon?

Would the other, similar, options move to the Scene tab as well? Namely the SSR Half Res Trace and Shadows High Bitdepth settings.

The "Unknown" hash above could indicate that this is a custom build, rather than the official build. If it is indeed a custom build, was it compiled with Open SubDiv support?

This goes beyond Blender. Blender does not exist in a vacuum. The vfx platform exists not to limit a piece of software's dependencies because they feel like it that year. It's there so "studios" can piece together the myriad of software required for their pipeline to support dozens of artists. A studio of any significance today is probably using Maya, Zbrush, Houdini, Nuke, etc. and yes, for the most part, they are all pretty well standardized to the platform's requirements. Even UnrealEngine is moving towards Python3 to align for instance [1].

One more thing for completeness. It looks like you're using 2.80. Can you try 2.81 (or 2.82) available for download here (just unzip locally and run): https://builder.blender.org/download/

Yes, lack of hardware will make this difficult to address. In the meantime please try the following:

You're hitting 2 known issues as part of: T67744 (some mentioned as part of T47030 too)

1. Why it doesn't use the 30% you have set in render properties might be the primary bug here. Manually shrinking your initial dimensions to 2100x5400 works
2. It's odd why blender eats up resources and typically needs to be manually killed in this instance... still needs investigated I suppose
3. It may never be able to render at that 18000 dimension (100%) in any case. OpenGL GL_MAX_TEXTURE_SIZE limits on my AMD FirePro W2100 card is 16384 and I'm not aware of any implementation that allows higher than that.

Can you try pulling down from git again. A large eevee refactor was reverted due to some other issues. See if you have better luck after.

Agree with the comment about color due to said issues. Try a different shape (diamond?) as you'll never find a good set of colors to differentiate.

It was never removed and is in nearly an identical spot - Did you mean something else? If not just follow these steps:

• N (to open the N-panel just as before)
• Click the View tab (similar to the old View sub panel)
• Click "Lock Camera to View"

Yeah, I seem to hit it when I scrub the smoothness value back and forth and that usually triggers the above after some time. I sometimes have to stop the scrub and play with the cut # too and then go back to smoothness scrubbing (and repeat) for it to hit.

I can repro, I think, but it took a long time of playing around to hit it -- So sadly I don't have a better simplified set of steps but I do have a stack:

This bug is probably the reverse of what's stated. The "Knobs" object has its "hide_render" visibility setting enabled -- use the Outliner filter to show the render visibility state.

Re-testing now since lots of time has passed. Good news is that the collection issue and the mesh separation issue seem fixed for some simple cases I've tried. Bad news is that the modifier issue still remains and can still be repro'd with the above blend and script.

Try running blender with the --factory-startup command line option. Your blender is new but your userpref.blend file is very, very old. There may be some incompatibility with it and --factory-startup will let us know.

Probably needs a style guide change as well. Just in these messages there's "Look Dev", "LookDev", and "look development"

Yes, it seems that "Dolly View" (Shift Ctrl Middle Mouse, and other forms of Dolly View) switches out from ortho. That's a fair bug I think.

Try using the build from today that came out <1h ago -- hash 16639c6f1a31

This is most likely a duplicate of either T59333 or T60733

Probably the same as T60733 as well as T59333. The model in question here has several faces with >170 vertices (massive n-gons).

It changed to bpy.ops.preferences.addon_enable a few days ago. Docs just haven't been updated for it yet.

This is not a bug right now, but rather the feature isn't coded yet and is a known limitation: https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/EEVEE (see the Limitations section at the bottom)

CTRL+B in edit mode is Bevel -- and the build yesterday had a crashing issue with Bevel for a few hours. A new build was released a few hours later -- can you try redownloading and trying again now?

A new build with a fix for this issue was just built. Give it another download/try now.

A new build with a fix for this issue was just built. Give it another download/try now.

A new build with a fix for this issue was just built. Give it another download/try now.

The bug tracker isn't a support system. A better place to troubleshoot this will probably still be with the addon author - try contacting him again. For instance, your second picture clearly indicates an old set of files attempting to be installed -- beyond the "upgrade to 2.8x required" message, the error message itself references "scene_update_post" which is no longer in 2.8 and is no longer in the addon developers git repository at that location either. Double-check where you got your zip from.

The lack of AA, right now at least, is due to reverting to the old way of drawing lines since there were so many complaints about wireframe (like on devtalk).