Particle HairKey[x].co gives always zero Vectors #60083

New Issue

Jose Conseco · 2019-01-02T20:25:24+01:00

Jose Conseco commented

2019-01-02 20:25:24 +01:00

When using:
bpy.context.active_object.particle_systems.active.particles- [x].hair_keys- [x].co
It gives Vector(0,0,0) for all X and Y values, for particle hair systems.
I believe it worked in earlier blender 2.8 builds - in beginning December and before.
I attached simple bend file with particle hair system and buggy one line of code script.
HairKeyCo_Bug.blend

When using: bpy.context.active_object.particle_systems.active.particles- [x].hair_keys- [x].co It gives Vector(0,0,0) for all X and Y values, for particle hair systems. I believe it worked in earlier blender 2.8 builds - in beginning December and before. I attached simple bend file with particle hair system and buggy one line of code script. [HairKeyCo_Bug.blend](https://archive.blender.org/developer/F6153244/HairKeyCo_Bug.blend)

Jose Conseco commented

2019-01-02 20:25:24 +01:00

Added subscriber: @JoseConseco

Philipp Oeser commented

2019-01-03 09:38:42 +01:00

Added subscriber: @lichtwerk

Philipp Oeser self-assigned this 2019-01-03 09:38:42 +01:00

Philipp Oeser commented

2019-01-03 09:38:42 +01:00

Confirmed, checking...

Philipp Oeser commented

2019-01-03 10:31:30 +01:00

Added subscribers: @mont29, @Sergey, @brecht

Philipp Oeser commented

2019-01-03 10:31:30 +01:00

Well from first investigation, we would need a way to flag RNA_def_property_float_funcs to be able to use context [FUNC_USE_CONTEXT].
This is because rna_ParticleHairKey_location_object_get / rna_ParticleHairKey_location_object_info check ParticleSystemModifierData->mesh_final which we can only get/evaluate using a depsgraph...
Looks like this is not possible atm., (or needs further investigation...)

As a workaround, you can use an evaluated object on the python side of things [which gives you correct coordinates] like so

import bpy

depsgraph = bpy.context.depsgraph
ob = bpy.context.active_object
obj_eval = depsgraph.objects.get(ob.name, None)

print(obj_eval.particle_systems.active.particles[10].hair_keys[5].co)

I would like to get opinions of other devs: @mont29, @brecht, @Sergey what do you think is the best way to proceed here? (I assume there are a couple of other occasions where property_float_funcs would benefit from having access to context?)
Or do we stick with the habbit of having to get the evaluated object from python first?

Well from first investigation, we would need a way to flag `RNA_def_property_float_funcs` to be able to use context [`FUNC_USE_CONTEXT`]. This is because `rna_ParticleHairKey_location_object_get` / `rna_ParticleHairKey_location_object_info` check `ParticleSystemModifierData->mesh_final` which we can only get/evaluate using a depsgraph... Looks like this is not possible atm., (or needs further investigation...) As a workaround, you can use an evaluated object on the python side of things [which gives you correct coordinates] like so ``` import bpy depsgraph = bpy.context.depsgraph ob = bpy.context.active_object obj_eval = depsgraph.objects.get(ob.name, None) print(obj_eval.particle_systems.active.particles[10].hair_keys[5].co) ``` I would like to get opinions of other devs: @mont29, @brecht, @Sergey what do you think is the best way to proceed here? (I assume there are a couple of other occasions where property_float_funcs would benefit from having access to context?) Or do we stick with the habbit of having to get the evaluated object from python first?

Jose Conseco commented

2019-01-08 21:37:46 +01:00

Thanks Philipp, depsgrapth thing work ok. It would be nice to have it working the old way, without the depsgrapth, unless it would be problem for performance.

Sergey Sharybin commented

2019-01-08 23:09:04 +01:00

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.

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.

Philipp Oeser commented

2019-01-15 13:42:06 +01:00

@brecht, @mont29: If this (what @Sergey mentioned) is the consensus, then this report can be closed?

Bastien Montagne commented

2019-01-15 16:48:42 +01:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2019-01-15 16:48:42 +01:00

Bastien Montagne commented

2019-01-15 16:48:42 +01:00

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).

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

Particle HairKey[x].co gives always zero Vectors #60083