Hi, I tried to shade flat through Geometry nodes and it worked.
I think that somehow the smooth shading (Phong angle in other software) is stored in the .abc and can't be overridden via operator, but geometry nodes do.

I was about to report this issue. Just want to mention and confirm that this isn't working on Linux also. It seems, visually, that the "Valley" is not working, I see that "Ridge" seems to be ok...

Hi. I tested the .blend file and I realize that after baking the Rigid Body with the operator "Bake to Keyframes" under Object/Rigid Body/Bake to Keyframes the simulation runs well with your settings.

This is my blender.crash.txt file

In T91981#1232089, @Hans Goudey (HooglyBoogly) wrote:

I'm honestly very suspicious about that result, the curve resample node should have nothing to do with hair particle combing. I can test to try to confirm later today though.

In T91981#1232086, @Everton Schneider (eversimo) wrote:

Hi! I just learned how to bisect and I can confirm that this problem came in with rB18959c502d62 but if I compile the commit before this one the hair comb is works fine. @Hans Goudey (HooglyBoogly) can you help?

Hi! I just learned how to bisect and I can confirm that this problem came in with rB18959c502d62 but if I compile the commit before this one the hair comb is works fine. @Hans Goudey (HooglyBoogly) can you help?

I'm able to select with "A" or select "tips" or "roots" and transform the strands with "G" "S" "R" shortcuts. But when trying to use any tool from the tool bar blender freezes.

I just made the same report here. I'm unable to comb hair, blender freezes.

Sorry... I just realize that there's already a report about this bug... T91981

But, I noticed that the "simple deform" modifier gets detected using the "mesh" shape and "deform" as source and also checking the "Deforming" checkbox right below (which I think is very annoying having to check a deforming checkbox even using deforming source... it's redundant) Check the file to see it working:

Hi! I can confirm it. The cloth modifier is not being considered on RBD "convex hull" shape and "deform" source and not even using "final" source which describes as considering "all modifiers". Tried "mesh" shape also but same result on every source mode...

(or you could build the shapekey yourself in Geometry nodes - interpolating existing meshes based on the vertexgroups)

Hi. I'm not a developer but I looked into your file and noticed some problems with the hair dynamic settings. After resetting all hair dynamics values to their defaults and changed a little the mesh (optimizing) and lowered the actual hair strands count and increased the count with children's particles(also with all values reset to defaults) it's working fine here.

Is it possible to update the fracture_modifier branch as it is right now to the recent blender master state? Or it's something very complicated? (sorry if it's not a place for this question...) I'm trying to build the branch but getting lots of errors with cmake, libraries... maybe it's too deprecated to the recent build system?

I can confirm that it's working fine again! Thanks team for making blender useful and stable every day! It's amazing the quality of the support, I feel the love and the care of you over this amazing software and the community, thank you all!

I can get point scale node working by feeding the node with a minimum value of 1. This way the point scale works again. Is this a real bug or the "design wherever it's called..." work this way now? Before we were able to use point scale directly with no need to give the node a starting point of 1. Now using only the point scale alone it assumes the scale starting point as 0 making the instances "disappear" and not allowing the scale to be increased.

I was about to report a segmentation fault while using the compositor also... not sure if it's related but I'm working on green screen footage using the keying node and when I change the feather distance value blender closes. The other way is when I connect some mask input to the garbage or core matte socket, It closes immediately. I need to use the 2.92 release to continue my work. It's working really well with the 2.92 release.

It's working fine here on 2.93 Alpha Master Build running in Ubuntu.

Sorry... I did mention a commit here and didn't know that it relates this bug with that commit... I don't know if it's related, I don't even understand how it works... Is it possible to cancel this mention and "undo" the relation of this bug with that commit?

@Bastien Montagne (mont29) is there something related to this commit? https://developer.blender.org/rB26fd55fad17f8177b52cf7c4bfe6d086e6ff1745 I'm not a coder, I don't understand about code, I'm just guessing based on the context of this commit...

Here is another file to exemplify better. We need to increase the viewport "strand steps" to give more resolution to the strand so we can see better the trajectory. The limit clicking the arrows is 7 but we can type higher values...

Ok... I'm going a little beyond here... but the purpose of this report is to know if it's possible to make Cycles render the strands in this special mode and to have control over the strands, just in the way that it is currently implemented... I know that there will be a full rewrite of particle code but it would be nice to have this option to "trace" particles paths as hair strands or even curves...

For the steps, well, you can use my file. Note that if you delete the bake there's no path (hair strands) because we need to bake/store the particle traveling in the space so blender can draw this path as a hair strand. There are no specific steps needed, just bake(store particles path info) particles in emitter mode and blender will be able to draw this path as hair.
Also, it would be SOOOOO HANDY to have an "automatic" start and end values based on particles life time... so we can synch the hair strand growing automatically over the particles life time. Now we have the start and end values under "timming" but it's hard to make the "growing effect" match the particles position exactly.

So, this is a feature that is being around since ever... I made use of it so many times but now for some reason, the hair strands are not rendering on cycles.
It's not in the hair mode, it's in the emitter mode. When the particle system is baked blender gives an option to render "the path" of each individual particle as hair. It works like a "particle tracer" and it uses hair strands to draw the path of the particles.
This is a very useful option, especially in motion graphics. A lovely option for blender users in my opinion, really powerful. But it would be nice to have it rendered in cycles also, not only in Eevee... and also would be nice to have the "Hair Shape"(root, tip, shape etc...) option exposed in the UI just as it is when in hair mode.

Thank you all involved!

I can confirm this problem. I was about to report the same problem but I found this report... so I'm here confirming the exact same issue with audio playback. I tested different audio methods in the blender system preferences (JACK, SDL, OpenAL...) I'm on Linux Ubuntu 20.04.1 LTS

I see that now the problem is solved:

This is awesome! I can't express how nice is this... to be able to follow a bug begin smashed! Everything is working so nice now! Thank you all!!! Special thanks to @Sebastián Barschkis (sebbas) ! You're doing an awesome job! Thanks!

@Iago Diogo Vasconcelos Mota (IagoMota) I'm testing here with current Master (2.90 alpha) didn't test with 2.83.
With 2.90 alpha the only thing that still happens is the vorticity spreading the smoke, but I'm not sure if this is the correct behavior, maybe this is the way it works and we need to keep really low values, I think it is very exaggerated with 0.3 but not sure...

The force field example is working fine to me. The smoke is immediately influenced by the force.

@Sebastián Barschkis (sebbas) Do you think that it is possible to keep the velocity data in the cache(I don't know exactly how it works so ignore my guessing)?
Also, what do you think that is causing the strange behavior with the smoke flow force field over particles? Do you know how to bring a similar behavior as before(old smoke system) or even better as discussed here?
Or the smoke force field behavior is a separate issue here?

This bug seem to be squashed to me.. I tested the attached files and they are working fine to me. Can you confirm this @Iago Diogo Vasconcelos Mota (IagoMota) ?