- User Since
- Jul 8 2020, 8:54 PM (115 w, 5 d)
Aug 26 2022
currently a limitation
Jun 25 2022
Jun 11 2022
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.
Apr 15 2022
Mar 24 2022
I can reproduce on Ubuntu 21.10 with a Threadripper 3000.
Cannot reproduce on Windows 10 with an i7 4790k or Threadripper.
Mar 22 2022
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
Roughness animated from 0 to 1
Mar 21 2022
Camera moves into it
Roughness is animated from 0 to 1
Roughness is animated from 0 to 0.1
Feb 4 2022
Feb 3 2022
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.
Feb 2 2022
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.
Dec 28 2021
Dec 26 2021
Increase "Min Light Bounces"
you can upload the file, it's just that we have to do the baking
Dec 14 2021
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
Nov 22 2021
Add the Render & Cycles project tag
Nov 13 2021
You should create another report for the rough one
Oct 30 2021
Oct 28 2021
While APIC has clear issues, it's Mantaflow that's the problem. T85212
Oct 27 2021
Here's another MGGX roughness related bug T92520
Sep 8 2021
Sep 5 2021
reason 52 why mantaflow sucks: mantaflow geometry
Aug 31 2021
Actually, never mind.
Aug 30 2021
Bounciness is just broken.
Jul 30 2021
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.
Jul 29 2021
26b2a35dd44c has fixed this.
Jul 28 2021
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.
Jul 21 2021
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.
Jul 8 2021
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.
Jul 5 2021
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.
Jul 2 2021
Add quick smoke to default cube. Set vorticity to .1.
Jun 18 2021
Most of it is just experimentation. What you'll find in the end are two main issues.
- 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?
- The domain is asymmetric.
Jun 3 2021
Jun 2 2021
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.
May 29 2021
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.
May 25 2021
Domain 768 with particle settings: upres 1, potential and update radius 1
May 23 2021
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
May 20 2021
May 14 2021
Same as T84001
Apr 18 2021
Viscosity testing. For PIC, FLIP ratio is set to 0. For FLIP, FLIP ratio is set to 1.
Apr 10 2021
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.
Mar 4 2021
Forgot to do liquids. APIC. By the way, version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: rB02948a2cab44
Mar 3 2021
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:
Feb 26 2021
D5797#237065 comment section?
Feb 25 2021
David's original scene Comptest Chain.blend (6mb) used three separate cubes each with a convex hull. This one works.
Then Dalai did some "cleanup" compound_collision_chain.blend (777kb) and merged those cubes, creating a concave shape that still has convex hull. This is what you download off of Blender. Doesn't work.
David then fixes this compound_collision_chain.blend (253kb) by separating the bottom cube and removing the rigid bodies from the wall.
Feb 22 2021
It's a limitation.
Feb 9 2021
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:
Jan 29 2021
Jan 7 2021
I found the issue. Collision sources Final and Deform don't work (as expected) but Base does.
Dec 30 2020
With respect to particles, initial velocity source does change the simulation, but at an imperceptible level compared to using meshes.
Dec 28 2020
It's called narrow band
Dec 23 2020
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
Dec 17 2020
Turn "Single Sided" off in the collision settings
Dec 15 2020
Blender's rigid body documentation is useless. But when you learn how to use it:
Nov 5 2020
I had no issues
Oct 27 2020
You are doing something wrong, I ran into no issues.
Sep 9 2020
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.
Aug 15 2020
Should have added that in the instructions, capsules push each other slightly while other primitives don't.
Aug 14 2020
Jul 8 2020
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