Page MenuHome

Add mesh addons don't support "align to view" properly
Closed, ResolvedPublic

Description

System Information
linux 64 bit

Blender Version
Broken: all

Short description of error
Have "align" setting in user preferences be set to "view". When adding new object, the object will have it's z towards the camera. If viewport is rotated and the addon settings are edited in the last operator panel, the object's rotation resets to view, which should not happen. Native blender objects retain their initial rotation without resetting on changing their settings, while all "add mesh" category objects reset their rotation, except bolt factory.
This rotation reset makes it impossible to see the effect changing many settings, mainly those affecting object height.

Details

Type
Bug

Event Timeline

Henrik Aarnio (hjaarnio) raised the priority of this task from to Needs Triage by Developer.
Henrik Aarnio (hjaarnio) updated the task description. (Show Details)
Henrik Aarnio (hjaarnio) set Type to Bug.
Brendon Murphy (meta-androcto) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Jul 30 2014, 11:18 AM

hi, I can confirm this error.
Blender 2.71

I can confirm this, too
Not a bug per se, just inconsistent with 'native' blender objects.
But I would prefer what @Henrik Aarnio (hjaarnio) mentioned (that is: only take rotation from view alignment on first execution, then reuse this rotation for tweaking settings)

Will propose solution based on 'AddObjectHelper' in a bit...

Most addons use bpy_extras.object_utils.object_data_add() to add their objects.
This will always align/reset to view (when the user preference is set to do this) - even on 'recalling' the operator with changed values (F6/last operator panel)
[just like @Henrik Aarnio (hjaarnio) mentioned]
This is understandable as the addon operators dont even have a place to 'store' the initial rotation from view for later calls. But there is a way around this.
Operators can already subclass a handy class called 'AddObjectHelper' in bpy_extras.object_utils. This makes sure the operators have a 'rotation', 'location' and 'align to view' property
which we can then use to achieve the desired behaviour (by passing in the operator to object_data_add()).

To make the behaviour more consistent with the 'native' blender objects (which align to view once on first execution and then keep the rotation valus on 'recalling')
I propose to make the following changes:

(1) change existing addons to also use/subclass AddObjectHelper
see attached patch 'T41183_addons'

(this covers 'addons', havent touched 'addons_contrib' yet [will wait for approval on the changes first...])
so in particular these are covered: AddMesh: ANT landscape, AddMesh: Extra Objects, AddCurve: Extra Objects

(2) change bpy_extras.object_utils.object_data_add() and AddObjectHelper
this will make sure the rotation is only taken from view-alignment _on first execution_.
Further calls will then reuse the rotation stored in the operator prop.
This will also add 'rotation', 'location' & 'align to view' settings to the operators UIs (which is nice in a way - also more consistent with 'native', but not sure this is wanted in all cases?)
To 'realign' to view user can uncheck 'align to view' (which will zero out rotation) and check again (which will then store the rotation from view to the operator prop again)
see attached patch 'T41183_bpy_extras'

(3) maybe we should also update the py-template?
see attached patch 'T41183_py-template'

(note: (external) addons which are not using the proposed method of subclassing 'AddObjectHelper' should hopefully not be affected by this proposed change at all.)
(note2: some addons dont use 'object_data_add()'/'AddObjectHelper' --> it is assumed that these deal with view-alignement themselves [aka BoltFactory/CurveAceousGalore] or simply ignore view-alignement, I guess?)

Let me know what you think...

Re: (1), looks good, supporting align to view is fine,

suggest to make col.prop(self, 'view_align')... block & other buttons into a function on AddObjectHelper draw_align() for eg.

OKi, added a function on AddObjectHelper draw_align() as campbell suggested
updated associated patches


@Campbell Barton (campbellbarton): what about the changes to the update logic of operator.rotation in (2) though? without them we wont see the desired behaviour (of 'only aligning to view on first exection' vs. 'aligning on view on every execution'?)
what about (3)?

regarding the updated patch.

  • prefer to have operator as named argument to create_mesh_object, and use name, create_mesh_object(..., operator=self)
  • Comment # draws generic transform props via helper function on AddObjectHelper is a bit redundant. think this can be removed everywhere.

updated patch

@Campbell Barton (campbellbarton): what was your opinion on the changes in bpy_extras.object_utils.object_data_add() and AddObjectHelper (T41183_bpy_extras.patch)? and the changes to the py-template, (T41183_py-template.patch)?
(basically points (2) and (3) in my second post)
Not sure how to proceed otherwise -- the changes to bpy_extras are mandatory to get this working...

just dropping chat with @Campbell Barton (campbellbarton) in IRC about this so it doesnt get lost...
[ if there's still something I can do --> shout at me:) ]

<ideasman42> lichtwerk, Checked patch, looks quite good
<ideasman42> align isnt really ideal term infact
<ideasman42> since it contains location
<ideasman42> draw_align()
<ideasman42> maybe draw_object_transform() ?
<ideasman42> better draw_transform()
<ideasman42> lichtwerk, besides that, seems fine
<ideasman42> lichtwerk, do you have commit access?
<lichtwerk> ideasman42: right, will change, but you'd have to commit (only have commit rights for addons -- not utils)
<ideasman42> lichtwerk, for simple rename I can do too
<lichtwerk> ideasman42: sure go ahead :)
<ideasman42> lichtwerk, oki, will do

closing, the bulk of add mesh addons support align to view.