@Sebastian Parborg (zeddb)
This is becoming a bit weirder than my artist brain can understand, first the tests.

@Sebastian Parborg (zeddb) ill try tonight and let you know

hi @Demeter Dzadik (Mets)
Im talking about objetct constraints not bone constraints, objects can have an armature constraint, i guess it was introduce in 2.83,
This operator copies the constraint properly from object to object .

hi, is there any news with this patch? it would be really handy to have a solution for the custom normal's issue during merging.

yes it doesn't make any sense to use those values, i found by accident that i can put those values, when i try to reproduce it i though it was an issue with selecting the four sliders at the same time and changing all the values at once but i was able to input the zeros one by one with no warning or the software canceling the input.
I made the report simply because it looked really weird but im not sure if it was an interface bug or just a WIP.

@Sebastian Parborg (zeddb) this is looking a lot better with today's build, could this be fixed by the updates that @Clément Foucault (fclem) did the lasts weeks?

I just fund out, im used to work with the origin of the object at 0,0,0 so to modifie the place and shape of the domain I use edit mode, it seems that mantaflow likes the origin in the center of the domain.
Not sure at this point if this is a bug or intended but its really weird and didn't see any entry/note about this in the manual besides this

Can confirm, that particular color theme its not being saved (HASH: 1a8642937dde )

can confirm, the viewport clip its not clipping selection or tools like polybuild, however poly build doesn't care if xray its on or off.
I was about to do the report but i was busy, thanks.

Marcin Twarowski, yes you are right its fixed, i didn't realize that much time had past since the last time i update my build.
Sorry guys my bad

that only origin its the same that we have in 2.79 try adding a few more objects and try rotate and scale them whit that turn on and off.
https://docs.blender.org/manual/en/latest/scene_layout/object/editing/transform/control/pivot_point/index.html

tested the last chair with a 2.82 win 7 nvidia 1070
Doesn't crash. . .
However it moves really slow in my machine(i have an nvidia 1070 and it moves slow) looking the file and there are some crazy shader groups, that makes my gpu ask for mercy.
This node group its inside the material "Cedar Wood" its connected to the color of the shader.

i got this result

can confirm the error, using 40a55be82cf5 win 7 x64 - gtx 1070 Drv: 430.86

does this task also affects the mirror vertex groups in the mirror modifier? or is that a completely independent topic?

Not only laptop users benefit from middle mouse emulation, the first time i use blender with that option and a tablet it worked great, that was one of those things that remove presasure from my right hand, not need to claw a finger to keep a middle mouse pushed was great and it still is today i basically only work with table mouse its only for games at this point.
If you are wondering about how do i select without doing a claw with my index or middle finger, i use right click with the side of my thumb (on the pen) or usually ctrl+left click (pen tip) to lasso select
Emulate 3 mouse button its not a default option, shouldn't actually be a problem if some noob its following a tutorial, becaouse probably never new that the option existed in the first place.
By the way alt+changing a parameter also doesn't work properly, i really don't care about that shortcut just use contextual menu>copy to selected, just mentioned if you wanted to added to the list.

the weird thing about this one its that the result may change and done properly depending on the scale and position of the object, i saw that since 2.5 but i was never able to get a file to consistently reproduce the behavior in order to report it
position 1:

just test it just for curiosity, its not only a visualization issue, it doesn't seems to be working at all.
I just added a displace to the plane and masked it with the group, works in 2.79, i also try baking the vertex group, didn't work in 2.8

if you use .png, remember to set the Color Space to "non color data" for normal maps.
This is also usually the case for metallic, roughness and other value based shader channels.

Can not confirm, works as it should for me, win 7 x64 nvidia 1070
Could you provide a simple .blend sample file?

Its a limitation at the moment in eevee at the moment works in cycles
https://docs.blender.org/manual/en/dev/render/eevee/limitations.html#cameras

i have a very similar cpu rig and works fine here, are u using any add-on? did you try loading factory settings?

A few days ago clement added extra things to normalize fireflies like that, the fixes in that report may be helping, altough the problem was focus on blend normals from the Ambient Oclussion, not sure if it is the same problem

I just tested with a0608340ae14 and i can't reproduce the error,
Win 7 - nvidia 1070 - Drv 430.86 - Wacom intuos 4 Drv:6.3.8

Hi, i have test with 4fb441517251, rendered that problematic shot a few times with different sizes and also other cameras, that blind guess seems to be working i didn't see any fire fly, this scene shots are rendering properly now.

1 open
2 render

I tested the fix with 8fa65ed31b7f and 8b2b79c2108b and the viewport looks great and mainly worked but. .

DANG! ok im feeling really really stupid right now, i though i had paked, and i was sure when was moving a file that weight more than an 1mb with only that little mesh data. . . . anyways, ill test this again in my secondary machine later to check this version.
Its kind a bit big but this is the file with the normal map.

Ok i have done more tests.
in my main machine (i7 win7 gtx 1070 ), updated drivers (430) an last blender version and the bug its consistently appearing always there.

ok, ill try to test this further, ill try to do it as soon as i can

This is what i get from the demo file.
Win 7 x64
Nvidia 1070 drivers 417.35