Particles python access is broken in 2.8 #58792

New Issue

lucas veber · 2018-12-05T14:37:14+01:00

lucas veber commented

2018-12-05 14:37:14 +01:00

Win10
Gtx 580

Blender 2.8 Beta and latest daily build

Accessing the particle_systems.particlesproperty is broken in Blender 2.8

Open the attached file
bug_particles.blend
It contains a cube with one particle system
Press Run Script to print the numbers of particles of this system via python, in the console
It returns 0 particles

Win10 Gtx 580 Blender 2.8 Beta and latest daily build Accessing the **particle_systems.particles**property is broken in Blender 2.8 - Open the attached file [bug_particles.blend](https://archive.blender.org/developer/F5834097/bug_particles.blend) - It contains a cube with one particle system - Press Run Script to print the numbers of particles of this system via python, in the console - It returns 0 particles

lucas veber commented

2018-12-05 14:37:14 +01:00

Added subscriber: @LucasVeber

blender-admin commented

2018-12-05 14:37:14 +01:00

#62837 was marked as duplicate of this issue

lucas veber commented

2018-12-07 13:17:26 +01:00

Evaluating the depsgraph first seems to fix it:

ob = bpy.context.active_object
eval_ob = bpy.context.depsgraph.objects.get(ob.name, None)
ps = eval_ob.particle_systems[0]

However not sure it's the correct approach, maybe it should be made obvious for users?

Evaluating the depsgraph first seems to fix it: ``` ob = bpy.context.active_object eval_ob = bpy.context.depsgraph.objects.get(ob.name, None) ps = eval_ob.particle_systems[0] ``` However not sure it's the correct approach, maybe it should be made obvious for users?

Omar Emara commented

2018-12-09 10:16:16 +01:00

Added subscriber: @OmarEmaraDev

Nicolas Antille commented

2019-01-22 14:55:19 +01:00

Added subscriber: @nantille

Nicolas Antille commented

2019-01-22 14:55:19 +01:00

Thanks Lucas for the code! It helps to at least have that.

Philipp Oeser commented

2019-01-22 15:07:22 +01:00

Added subscribers: @mont29, @Sergey, @lichtwerk

Philipp Oeser commented

2019-01-22 15:07:22 +01:00

Changed status from 'Open' to: 'Resolved'

Philipp Oeser closed this issue

2019-01-22 15:07:22 +01:00

Philipp Oeser self-assigned this 2019-01-22 15:07:22 +01:00

Philipp Oeser commented

2019-01-22 15:07:22 +01:00

There is a similar case in blender/blender-addons#60083.

Quoting from there:

In blender/blender-addons#60083#596434, @Sergey wrote:
From predictability point of view using an explicit evaluation object from a script will be preferable solution: this eliminates possibility of system silently switching to an object instance which you don't intent to. Points are:

Access to any ID field should be following one rule (as in, it shouldn't be reading some fields from given ID and other fields from an evaluated ID).

Scripts need to be able to read write fields which are considered inputs for evaluation.
So from this point of view i am in favor of leaving it up to script to decide what ID to access.

In blender/blender-addons#60083#600524, @mont29 wrote:
Yes, totally agree with @Sergey here. We do have a few helpers (like for raycast) where is sort of make sense to implicitly get the evaluated data from context's depsgraph, but think this should remain an exception (and a documented one).

So the solution @LucasVeber posted is the preferred and correct one.
Guess this can be closed then...

There is a similar case in blender/blender-addons#60083. Quoting from there: > In blender/blender-addons#60083#596434, @Sergey wrote: > From predictability point of view using an explicit evaluation object from a script will be preferable solution: this eliminates possibility of system silently switching to an object instance which you don't intent to. Points are: > - Access to any ID field should be following one rule (as in, it shouldn't be reading some fields from given ID and other fields from an evaluated ID). > - Scripts need to be able to read write fields which are considered inputs for evaluation. > So from this point of view i am in favor of leaving it up to script to decide what ID to access. > In blender/blender-addons#60083#600524, @mont29 wrote: > Yes, totally agree with @Sergey here. We do have a few helpers (like for raycast) where is sort of make sense to implicitly get the evaluated data from context's depsgraph, but think this should remain an exception (and a documented one). So the solution @LucasVeber posted is the preferred and correct one. Guess this can be closed then...

Philipp Oeser commented

2019-03-22 11:56:09 +01:00

Added subscriber: @BlenderTim

Georg K commented

2019-05-30 18:14:10 +02:00

Added subscriber: @georgK

Georg K commented

2019-05-30 18:14:10 +02:00

Does this still apply? I changed the code in the attached blend to

import bpy

ob = bpy.context.active_object
eval_ob = bpy.context.depsgraph.objects.get(ob.name, None)
ps = eval_ob.particle_systems[0]

print(len(ps.particles))

But I get "AttributeError: 'Context' object has no attribute 'depsgraph'" - am I doing something wrong?

Does this still apply? I changed the code in the attached blend to ``` import bpy ob = bpy.context.active_object eval_ob = bpy.context.depsgraph.objects.get(ob.name, None) ps = eval_ob.particle_systems[0] print(len(ps.particles)) ``` But I get "AttributeError: 'Context' object has no attribute 'depsgraph'" - am I doing something wrong?

Sergey Sharybin commented

2019-05-30 18:31:22 +02:00

@georgK, the API has been changed in e693918d40: to access dependency graph use context.evaluated_depsgraph_get().
The API docs will be updated soon.

@georgK, the API has been changed in e693918d40: to access dependency graph use `context.evaluated_depsgraph_get()`. The API docs will be updated soon.

Georg K commented

2019-05-30 18:53:03 +02:00

Thank you!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Particles python access is broken in 2.8 #58792