currently a limitation

In T97870#1355262, @Olivier Maury (omaury) wrote:

This is unfortunately a limitation of the current implementation: We assume that there is only 1 bsdf per refractive interface casting shadow caustics, which explains why only the 1st bsdf is taken into account. This may change in the future, since I can imagine how a variant of the setup you have here could be used for dispersion.

Windows 10, GTX 1080Ti

It has to do with Filmic. In 3.2, both Filmic and Filmic Log get the black spot. In 3.1, only Filmic Log gets the black spot.

related? T97259

I can reproduce on Ubuntu 21.10 with a Threadripper 3000.
Cannot reproduce on Windows 10 with an i7 4790k or Threadripper.

If you move the camera in this report's file, you get the same artifacting. They're just elongated in the cylinder's direction.

Camera moving in

Camera rotating

Roughness animated from 0 to 1

Camera moves into it

Camera rotates

Roughness is animated from 0 to 1

Roughness is animated from 0 to 0.1

Showing how smoke resolution relates to block size.

It's because you simulated it at a lower resolution, making the blocks almost fill the hourglass. As I mentioned in the detailed report, this matters.

You should merge this report to T94425, I describe the issue better there. And I can still reproduce on the latest 3.1 beta and 3.2 alpha.

Increase "Min Light Bounces"

you can upload the file, it's just that we have to do the baking

1080 Ti, 4790k, 16Gb of RAM
I can go up to 8000 before I run out of ram.
It takes like 40 seconds to change pixel size. Performance seems consistent.

no issue with a recent build

Latest alpha has no issue for me

Add the Render & Cycles project tag

You should create another report for the rough one

While APIC has clear issues, it's Mantaflow that's the problem. T85212

Here's another MGGX roughness related bug T92520

source 0

source 1

source 2

reason 52 why mantaflow sucks: mantaflow geometry

flipfluids geometry

Actually, never mind.

Bounciness is just broken.

Why do the bounces seem to occur at different heights? Not enough temporal resolution since the FPS is too low. Set your FPS to 240 or higher. At frame 9→10, the ball travels 14.5cm. Between frame 10 and 11, Bullet substeps 50 times which allows the ball to correctly bounce. Set the substeps to 1 and you will see that the ball "correctly" continues downward, penetrating the floor.

Look at it tip from a single vertex to a square that's 10mm large. Very nice.

26b2a35dd44c has fixed this.

I can at least commend you for setting object scales to 1. However, using highly detailed geometry and the mesh solver is where you made your mistakes.
For the first file, what is the intent? Do you want a sphere or a highly faceted ball? If you want a sphere, why don't you use the sphere solver? If you want a highly faceted surface then the real issue is that you have a flat ground plane using mesh. Simply change the ground to box, and after 15 seconds, the ball will come to rest. This is entirely accurate since the center of gravity is much higher than the little triangle that its trying to balance on. This is simply user error.

It's not the wall that's broken, but surprisingly the floor. It's like an invisible force field. Sometimes it acts like a solid. Once the bug is interacted with by some rigid body, following rigid bodies are fine. But it can only be moved along the Z-axis. Changing to box collider or removing and apply rigid body does nothing. What a weird bug.

I also tested rigid bodies and cloth. It looks like that the playback delay from other bakes is added to whatever you're currently baking. So a new task or title change should be done.
We can see that after I delete the cloth, the smoke sim bakes very quickly.

Remembering the speed of a normal smoke bake, we can see that the rigid body sim also slows down the smoke bake.

Same thing happens even when they're different.

I have a smoke sim with domain 256 baked to frame 40. When the particle sim is baking from frame 1-40, it is slow, but after that, as fast as normal. It is 100% dependent on what the fluid sim is.

Add quick smoke to default cube. Set vorticity to .1.

Most of it is just experimentation. What you'll find in the end are two main issues.

1. Large timesteps cause strange behaviors in the base simulation.
   • Also affects vorticity and dissolve as if the influence of these isn't divided by the timestep. I don't know if it directly affects fluid particles. Since the simulations are overly energetic at high timesteps, is the increase of particles from the base sim or timestep?
2. The domain is asymmetric.

Things I found. Angular Limit cannot be animated, but it does apply only when it goes back to frame 1. Enabled and Breakable can be animated freely. Disable Collisions can be animated freely, but a weird thing can happen in this particular scene. If the "door" doesn't have enough energy to penetrate the cube, they will not intersect when collisions are disabled. Sometimes, weird things will happen like at 1:08. I've also seen the door very slowly penetrate the cube.

I've come across this issue as well. Whenever you're animating a rigid body on frame 1 or before, it bugs out like that. The workaround is to not use frame 1.

Domain 768 with particle settings: upres 1, potential and update radius 1

Your resolution is too low.
Your setup. Domain 64 with particle settings: upres 1, potential and update radius 1

Domain 64 with default particle settings: upres 1, potential and update radius 2

Domain 64 with particle settings: upres 10, potential and update radius 4

Domain 128 with default particle settings: upres 1, potential and update radius 2

Domain 256 with particle settings: upres 1, potential and update radius 1

Same as T84001

Viscosity testing. For PIC, FLIP ratio is set to 0. For FLIP, FLIP ratio is set to 1.

As Philipp said, they changed the "time resolution" setting for rigid bodies. When we set the time settings to the equivalent of pre 2.90 (600steps per second/24fps = 25 steps per frame) we get it to work in real time.

Forgot to do liquids. APIC. By the way, version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: rB02948a2cab44

Create two cubes. The domain is 25cm25cm50cm at 0X 0Y 15cmZ and the cube is 10cm10cm10cm at 0X 0Y 0Z. Everything is default expect for the timestepping.

Can't believe I didn't think of this. Here are some tests of 2400 fps simulations with no timestepping, the temporal equivalence of 24 fps and 100 timestepping.
Smoke, 64 domain, 2400fps edited to real-time. Looks exactly like 24fps with 100 timestepping:

D5797#237065 comment section?

David's original scene Comptest Chain.blend (6mb) used three separate cubes each with a convex hull. This one works.

It's a limitation.

The "issue" that I had was that the size of the simulation was too small for the timestep size. Normal 50 in meter sized sims works fine:

I found the issue. Collision sources Final and Deform don't work (as expected) but Base does.

With respect to particles, initial velocity source does change the simulation, but at an imperceptible level compared to using meshes.

It's called narrow band

Here I compare between 0 and 100 (max) for the initial velocity. There's very little difference in using the maximum value.

version: 2.92.0 Alpha, branch: master, commit date: 2020-12-20 17:48, hash: d283a093d664

Turn "Single Sided" off in the collision settings

Blender's rigid body documentation is useless. But when you learn how to use it:

I had no issues

You are doing something wrong, I ran into no issues.

The September 7 dev notes mentioned an update to the Bullet library. I downloaded b351607996e4 and the issue wasn't there. Every primitive can be used now! The last thing to make rigid bodies perfect is resolving the need to enable a collision margin of 0m to fix some interactions, but I can wait for that.

Should have added that in the instructions, capsules push each other slightly while other primitives don't.

2.83
I too have encountered this problem.
Some testing I did:
1 rigid to 50 objs = 0m:16s
1 rigid to 100 objs = 0m:33s
1 rigid to 150 objs = 0m:49s
1 rigid to 200 objs = 1m:07s
1 rigid to 250 objs = 1m:23s
1 rigid to 500 objs = 2m:58s
1 rigid to 1000 objs = 5m:52s
1 rigid to 2000 objs = 12m:02s
1 rigid to 5000 objs = 36m:52s