Page MenuHome

Particle HairKey[x].co gives always zero Vectors
Closed, ArchivedPublic

Description

When using:
bpy.context.active_object.particle_systems.active.particles[X].hair_keys[Y].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.

Details

Type
Bug

Event Timeline

Philipp Oeser (lichtwerk) triaged this task as Confirmed priority.Thu, Jan 3, 9:38 AM
Philipp Oeser (lichtwerk) claimed this task.

Confirmed, checking...

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: @Bastien Montagne (mont29), @Brecht Van Lommel (brecht), @Sergey Sharybin (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?

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.

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.

@Brecht Van Lommel (brecht), @Bastien Montagne (mont29): If this (what @Sergey Sharybin (sergey) mentioned) is the consensus, then this report can be closed?

Bastien Montagne (mont29) closed this task as Archived.Tue, Jan 15, 4:48 PM

Yes, totally agree with @Sergey Sharybin (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).