@Germano Cavalcante (mano-wii) @Campbell Barton (campbellbarton) Do you guys have any input on this?

I've updated the patch based on the feedback.

Simplified the volume calculation method and unified the method into a new math function.
I made the other parts of blender that uses this method use this function as well.

I've uploaded my current take on this here: D5473

@Jacques Lucke (JacquesLucke) yes it is supported.

Yepp, that is how it currently works. It doesn't spread out the mass evenly it just assigns each vertex the set weight.
I could easily fix this and I think I actually should. So we instead have an actual density going on instead.

This is intended. The render visibility only work in final renders now (F12).

Your GPU is too old and will not run blender 2.8. You will indeed have to invest in a modern computer if you want to run 2.8

@Clément Foucault (fclem) I guess we just add Vega M to the GPU string list?

This sounds like you are simply running out of memory on your GPU.

@Brecht Van Lommel (brecht) is hot plugging supported?

Your GPU is too old and we do not support it anymore. You need a newer GPU for 2.8

That is not the same issue as you described in the initial report though. It creates a face in your latest example.

This patch is very straightforward and doesn't add that much complexity. So I will try to get this merged into 2.81.

Is this still and issue with the latest build from here? https://builder.blender.org/download/

Fixed the symmetrical problems. Now it seems to work with the non uniform suzanne mesh!

I've updated the patch to 2.80. But it only seems to work well on symmetrical, uniform meshes. Otherwise it will start sliding and floating around.

I can reproduce this too.

I've just tried this with llvm 10 and mesa git. Now it does compile the kernels for the default cube scene in about 30 sec, so that's good. But it locks up the system completely when trying to render.
With llvm 8 and 19.1.3 it also locks up my system.

I'm guessing that this is indeed a bug judging from the tool tips on the different options.

Awesome! I think this issue is also present with texture painting. That is with input devices with high polling rate (like 1000Hz mice), some operations are executed way to often and causes blender to slow down to a crawl.

We need a bit more concrete step to be able to look into this issue.
Exact steps to make it crash would be awesome to have.

You need to have the same subdivision level in the render setting as in the viewport. Otherwise the cloth cache will not match and you will have issues like these.

I've posted a fix: D5416

@Brecht Van Lommel (brecht) who to assign this to?

Can't reproduce this with the steps provided. This is probably a duplicate of T65585 but I can cut a 100m plane without any issues. So you need to be a bit more specific (and preferably provide a sample .blend file).

Ok then.

I can't reproduce this either.

I can't reproduce this. I open the file and hit F12 and it seems to render out fine.

@Sergey Sharybin (sergey) It doesn't simulate correctly with render animation (both cycles/eevee). It only works if you have baked the particle system. I could have sworn we already had an issue with this, but I can't find it :/

@Clément Foucault (fclem) is this a bug or a limitation with eevee?

You are running an Ivy bridge CPU:
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Seventh_generation

You need to remove dithering (set it to 0) to not get these noise patterns in the output:
https://docs.blender.org/manual/en/latest/render/output/settings.html?highlight=dithering#dithering

The texture nodes are not setup to handle/use transparency. This is not a issue with blender but a texture node setup issue.

As mentioned, eevee only handles one refraction event: https://docs.blender.org/manual/en/dev/render/eevee/limitations.html#screen-space-refraction
So the others are left out. This is not a bug but a limitation of the eevee render engine.

Your GPU is too old and we do not support it anymore. You will have to get a newer GPU to run 2.8

Just to be clear, you get the same error message when building blender yourself or using the precompiled build bot version?

The artists (Nacho) scenario only decimated one curve at the time. And it was also on baked key frames.

In D4841#122652, @Brecht Van Lommel (brecht) wrote:

Agree we could use a better metric here, especially if you're editing multiple curves at once a ratio is not useful.

I've posted a fix here: D5401

I should rephrase, xinput does not see the tablet as a wacom tablet.
I guess that we can just add teh xwayland generic tablet names to our white list. I can try to take care of this as I run wayland too.

@Brecht Van Lommel (brecht) this is running wayland. I'm guessing the QT and GTK (Krita and GIMP) have working tablet support in wayland.

Yepp, my bad. I didn't read all the text...

Your build is missing libXi (Xinput). Install libXi dev package and recompile blender. We have added a fatal warning about this, so if you try to build and are missing libXi with the latest master, it will error out.

This is not really a bug. As mentioned, a know inconvenience and will be fix eventually

Your GPU is too old and we do not support it.

Your GPU is too old to run blender and we do not support it

Your GPU is too old and we do not support it.

You do not meet out minimum GPU requirements. You need a better computer to run blender 2.8

@Campbell Barton (campbellbarton) @William Reynish (billreynish) I'm guessing that these should be available in a menu somewhere?

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.