[Bf-python] Bf-python Digest, Vol 133, Issue 11
James Crowther
jamesharrycrowther at gmail.com
Wed Jun 29 02:48:54 CEST 2016
Hi Diego!
Thanks for replying! In each case where my script finds the value of
the 'dupli
group' attribute to be None, the actual value of this attribute is a group.
In each such case i manually check this from the python console window
using
>>>D.objects['some_object'].dupli_group
bpy.data.groups['some_group']
so there is definitely a group that is being referenced, its just my script
keeps returning with the dupli_group attribute as None which is incorrect,
it should return the same value as the code above! This is confusing since
my script should be able to see the group just the same as the code run in
the console window!!
Hope this makes sense!
Kind regards'
James
On Tue, Jun 28, 2016 at 8:00 PM, <bf-python-request at blender.org> wrote:
> Send Bf-python mailing list submissions to
> bf-python at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.blender.org/mailman/listinfo/bf-python
> or, via email, send a message with subject or body 'help' to
> bf-python-request at blender.org
>
> You can reach the person managing the list at
> bf-python-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-python digest..."
>
>
> Today's Topics:
>
> 1. dupli_group attribute of ID Object (James Crowther)
> 2. Re: dupli_group attribute of ID Object (Diego Borghetti)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Jun 2016 17:01:19 +1000
> From: James Crowther <jamesharrycrowther at gmail.com>
> Subject: [Bf-python] dupli_group attribute of ID Object
> To: bf-python at blender.org
> Message-ID:
> <
> CAJOwpNt6P12xa1XvSyTK2vZY-VQpmY5XtHos2hG0x1TjQkxbOQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi there,
> I'm in need of some help with understanding the 'dupli_group'
> attribute. I have a script that looks at this attribute to find what groups
> are there. But, most of the time my script returns that this attribute is
> None. Occasionally it will return the group which I assume is the normal
> behaviour of this attribute. It seems to be random whether my script finds
> the attribute to contain the correct value.
>
> I'm trying to debug why this might occur. I have a theory that it may be
> because my script attempts to determine which attributes are readonly; by
> attempting to write to all the attributes of the object in question. For
> example, take the cube on the default scene. I do this by using the
> following:
>
> for attr in dir(D.objects['Cube']):
>
> # get the data of the attribute
> attr_data = getattr(D.objects['Cube'], attr)
>
> if type(attr_data) in {str, int, Vector, Color, Euler, float, bool}:
>
> try:
>
> setattr(D.objects['Cube'], attr, attr_data)
>
>
>
> except:
> read_only.append(attr)
>
> elif type(attr_data) is None:
> #add the attribute to a list of attributes that are not yet initialised
> with any data.
> cls_uninitialised.append(attr)
>
>
> This is all done during one update frame in blender, the above code is
> called from a handler in bpy.app.handlers.scene_update_post
>
> As far as I can tell this is the only attribute that does this. Most of the
> time the 'dupli_group' attribute ends up in in the cls_initialised list
> since the result of type(attr_data) is None. But when I check manually for
> example:
>
> >>>D.objects['some_object'].dupli_group
> bpy.data.groups['some_group']
>
> So, I guess I'm really interested to know if dupli_group is always
> guaranteed to have a value if the object is actually using it and if
> setting other attributes of the same object might cause it to momentarily
> be set to None.
>
> Since this behaviour appears to be random at the moment, I am guessing it
> could be due to the fact that python dictionaries store key, value pairs in
> a different order each time and occasionally this order results in the
> dupli_group attribute being something other than None in my code.
> That is a long shot though, since it seems rather odd that this would be
> the case.
>
> I'd appreciate answers to my direct question on the effect of setting
> attributes and also any other ideas for things to try!
>
> Thanks!
>
> James
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-python/attachments/20160628/4ea6a501/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 28 Jun 2016 08:46:49 +0100
> From: Diego Borghetti <bdiego at gmail.com>
> Subject: Re: [Bf-python] dupli_group attribute of ID Object
> To: Blender Foundation Python list <bf-python at blender.org>
> Message-ID:
> <
> CAABZ__tbpiKZZsvWOxXkORRkQJ7XU+kPrMEX9Yhi7Dhs-jxPXA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Check the value of dupli_type.You can have dupli_type set to GROUP but
> with no group assign (which it's fine). It will be easy if you add and
> empty and check in the Object properties how it works (under
> Duplication). Or at least that is what I do from my scripts :P
>
> I never check, but I assume that if dupli_type is set to anything
> else, the default value of dupli_group will be None (because there is
> no use of the attribute).
> Campbell, is this right ?
>
> On Tue, Jun 28, 2016 at 8:01 AM, James Crowther
> <jamesharrycrowther at gmail.com> wrote:
> > Hi there,
> > I'm in need of some help with understanding the
> 'dupli_group'
> > attribute. I have a script that looks at this attribute to find what
> groups
> > are there. But, most of the time my script returns that this attribute is
> > None. Occasionally it will return the group which I assume is the normal
> > behaviour of this attribute. It seems to be random whether my script
> finds
> > the attribute to contain the correct value.
> >
> > I'm trying to debug why this might occur. I have a theory that it may be
> > because my script attempts to determine which attributes are readonly; by
> > attempting to write to all the attributes of the object in question. For
> > example, take the cube on the default scene. I do this by using the
> > following:
> >
> > for attr in dir(D.objects['Cube']):
> >
> > # get the data of the attribute
> > attr_data = getattr(D.objects['Cube'], attr)
> >
> > if type(attr_data) in {str, int, Vector, Color, Euler, float, bool}:
> >
> > try:
> >
> > setattr(D.objects['Cube'], attr, attr_data)
> >
> >
> >
> > except:
> > read_only.append(attr)
> >
> > elif type(attr_data) is None:
> > #add the attribute to a list of attributes that are not yet
> initialised
> > with any data.
> > cls_uninitialised.append(attr)
> >
> >
> > This is all done during one update frame in blender, the above code is
> > called from a handler in bpy.app.handlers.scene_update_post
> >
> > As far as I can tell this is the only attribute that does this. Most of
> the
> > time the 'dupli_group' attribute ends up in in the cls_initialised list
> > since the result of type(attr_data) is None. But when I check manually
> for
> > example:
> >
> >>>>D.objects['some_object'].dupli_group
> > bpy.data.groups['some_group']
> >
> > So, I guess I'm really interested to know if dupli_group is always
> > guaranteed to have a value if the object is actually using it and if
> setting
> > other attributes of the same object might cause it to momentarily be set
> to
> > None.
> >
> > Since this behaviour appears to be random at the moment, I am guessing it
> > could be due to the fact that python dictionaries store key, value pairs
> in
> > a different order each time and occasionally this order results in the
> > dupli_group attribute being something other than None in my code.
> > That is a long shot though, since it seems rather odd that this would be
> the
> > case.
> >
> > I'd appreciate answers to my direct question on the effect of setting
> > attributes and also any other ideas for things to try!
> >
> > Thanks!
> >
> > James
> >
> >
> >
> > _______________________________________________
> > Bf-python mailing list
> > Bf-python at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-python
> >
>
>
>
> --
> --
>
> Diego
>
>
> ------------------------------
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> https://lists.blender.org/mailman/listinfo/bf-python
>
>
> End of Bf-python Digest, Vol 133, Issue 11
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20160629/822fcc15/attachment.html>
More information about the Bf-python
mailing list