Page MenuHome

Image Empties: Make them usable
ClosedPublic

Authored by Jacques Lucke (JacquesLucke) on Oct 8 2018, 2:07 PM.

Details

Summary

One weird behavior is that sometimes the view_align option is not used even though it is activated.
This happens because this line only seems to check if the view_align property has changed since the last operator invocation (and not if it changed from the original default).
If it did not change, the global setting in the user prefs is used and not the one in the operator.
Maybe it is intended this way but for me it felt wrong that sometimes the image is not aligned to view even though the setting is enabled.

Diff Detail

Repository
rB Blender
Branch
image_empties (branched from blender2.8)
Build Status
Buildable 2201
Build 2201: arc lint + arc unit

Event Timeline

Brecht Van Lommel (brecht) requested changes to this revision.Oct 8 2018, 3:10 PM

That behavior is indeed a bug. Whenever we have user preferences determine the default of an operator property, it should set the property to the value from the user preferences in invoke(). That way it will be shown to the user.

However, I don't think this operator should use the view align user preference. For 2D images it makes sense to always align them, but you don't want to require users to enable it for 3D objects as well.

Instead I think this operator can get its own property that defaults to View Align. Maybe even better if it's an enum with options Align to View / Left / Right / Top / Bottom / Front / Back.

Rather than location it could have some offset from the center, defaulting to e.g. 10. You don't usually want the reference images to be at 0,0,0.

This revision now requires changes to proceed.Oct 8 2018, 3:10 PM
  • align to view when dropping images + make gizmo work
  • new Align Objects to View operator

When I load a new image and use the Align Objects to View operator, sometimes I get this warning:

find_node_operation: Failed for (COPY_ON_WRITE, '')
add_relation(Eval Order) - Could not find op_from (OperationKey(t: 11, cn: '', c: COPY_ON_WRITE, n: ''))
add_relation(Eval Order) - Failed, but op_to (OperationKey(t: 11, cn: '', c: COPY_ON_WRITE, n: '')) was ok

Everything works as expected besides that. I still have to figure out what causes it.

I'm not sure if it makes sense to position the new empty at any specific location. The artist will have to tweak the location anyway. Any default that we could use would only be a guess and it could just be wrong. I think it is better to follow the "principle of least surprise" here.
Also options for Left/Right/... in the importer are not really needed imo. My guess is that it is easier to just position the image afterwards or get into the right view beforehand.

I also expect that drag and drop from a file browser will be used more in practice.

[EDIT:] One thing we could do is to position a new aligned image behind the selected object. Or in case of drag and drop, behind the object under the mouse.

Fair enough. Maybe I'm being too conservative in wanting an equivalent for the old workflow. I think once you know to align the view in advance it is quicker anyway.

Perhaps the right solution is really to have an option to display images always in the background & in ortho view only? Then the location doesn't matter so much.

What I also noticed testing this is that the image added is quite small, by default I can't even see it because it's inside the default cube. It is kind of arbitrary and not every scene is a default cube, but we should probably make it bigger so at least the most basic case is not confusing.

  • larger default size for image empties
  • fix image empty gizmo in orthographic view
Jacques Lucke (JacquesLucke) retitled this revision from Image Empties: align image empty to view to Image Empties: Make them usable.Oct 9 2018, 11:05 AM

I wanted to try out the orthographic-only visibility but I could not figure out how that should be implemented yet.
Also I don't know how do draw them only in the background yet.

But I wonder if we really want this/I don't know how important it is. I'm not sure how well this fits into the idea of having image empties...
Maybe we'll need something like the old background images anyway, in theory we could also have both.

Looks good to me now.

But I wonder if we really want this/I don't know how important it is. I'm not sure how well this fits into the idea of having image empties...
Maybe we'll need something like the old background images anyway, in theory we could also have both.

The whole plan was to avoid having both though, see T52668: Proposal: Replace background images with Image Empties in 2.8x.

@Campbell Barton (campbellbarton) might want to chime in regarding the design, and @Clément Foucault (fclem) may have some hints for the implementation.

I don't think an option to always draw in the background is too far-fetched, we also have "In Front" for objects which is kind of similar.

This revision is now accepted and ready to land.Oct 9 2018, 12:38 PM