Page MenuHome

Particle Collision failing in blender 2.80
Confirmed, HighPublicBUG

Description

Blender Version
Broken: (example: 2.80rc1, 2.83
Worked: (optional) : 2.79b

Short description of error
My case is that when a collision object moves towards a bunch of particles which has zero velocity, in 2.79b the particles were ricocheted but in 2.80 they go straight.

Exact steps for others to reproduce the error

  1. Open Attached file in 2.79b and 2.80
  2. Run animation and compare

Revisions and Commits

Event Timeline

Jacques Lucke (JacquesLucke) lowered the priority of this task from 90 to Low.Aug 7 2019, 4:22 PM

I can confirm the issue, but it is unlikely that this is going to be fixed.. The current particle system is considered to be end-of-life.

Hmm... I think the problem doesn't belong to particle system, but belongs to collision system.
In 2.79 the collision works greatly!, but in advanced 2.8 version, it doesn't work correctly.
I think the new advanced version should include all of the prior version's functionalities except when there are some inevitable reasons that some functionalities should be excluded.

I discovered this error when I was following the Blender Guru tutorial (https://www.blenderguru.com/), and the title is 'glass smashing (https://www.youtube.com/watch?v=9L8qOq1Shiw&t=2096s)' which explains the glass shards tutorial using
collision system with particles.

Thank you !

Germano Cavalcante (mano-wii) renamed this task from Particle Collision Bug to Particle Collision failing in blender 2.80.Tue, Feb 4, 2:56 PM
Germano Cavalcante (mano-wii) raised the priority of this task from Low to High.
Germano Cavalcante (mano-wii) updated the task description. (Show Details)
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".

After investigating a little, I realized that the reason for the failure is the Rigdy Body.
There is something wrong with updating the object's matrices in 2.80.
I suspect it is a lack of sync between the evaluated object and the original.

After investigating, I realized that depsgraph calls 3 eval functions in a problematic order.

  1. BKE_object_eval_local_transform
  2. BKE_object_eval_uber_data
  3. BKE_rigidbody_eval_simulation

BKE_rigidbody_eval_simulation updates ob->obmat according to Rigid Body simulation. This obmat is that seen in the 3dview.
BKE_object_eval_local_transform takes values like ob->loc, ob->rot and ob->scale to update ob->obmat, resetting it to the value before BKE_rigidbody_eval_simulation.
BKE_object_eval_uber_data updates the collision modifier with the same obmat before BKE_rigidbody_eval_simulation. (It is as if the object does not move).

One solution would be to call BKE_object_apply_mat4 and change ob->loc, ob->rot and ob->scale during the BKE_rigidbody_eval_simulation. But I don't know if this is the most correct. BKE_object_eval_local_transform should only be called at the end. No?

@Sergey Sharybin (sergey), would you have any light on this subject?