Bye bye BackgroundBitmaps

I’m not sure about this either. Maybe we just automatically put them on their own layer and let users turn them on, off, and lock from there. Users should know about layers and the on/off/lock controls are easy to find.

@BrianJ, I agree that is is possible to do these with the current materials UI. but unless someone is a complete rendering geek you will never be able to find those settings or you might try a dozen others before you found the right ones.

Plus I don’t think one more simplified “image” material is all that confusing. It is the most common rendering material I want to use and it is painful to set up a simple image material unless I’ve figured out that I can drag and drop a bitmap on to an object.

I’m not sure what to think about this. Where would this go in the UI? Is it yet another hack? Perhaps @jeff can tell us how BackgroundBitmaps are hacked in. Would it be the same?

Another issue that hasn’t been addressed is that BackgroundBitmaps are per viewport. Currently we don’t have a way to turn off PFs per viewport and since ImagePlane is just a tune up of PF, I’m expecting they will show in all viewports without an easy way to turn them off in some.

Is this a problem? Am I confused?

One more thing… There seems to be an issue with the edge showing on a PictureFrame. If you want to print a view that has a PF, unless the viewmode turns off edges on all objects then the PF edges show. There isn’t a way to turn them off only on a PF as near as I can tell.

Am I confused?

That is true Bob.

There are arcane ways to fake it but nothing as clear as an option for the border thickness.

I just notice another PictureFrame hack.

It seems that the Isocurve Density setting on the object is ignored in the display pipeline and perhaps in rendering. @jeff and @andy, is this true?

Is there a need for this, or can we just set the Isocurve Density to -1 when the ImagePlane is placed?

Added my comments-

Also, Adjusting the contrast is necessary but for backgroundbitmap style use, I find adjusting transparency works well for this, so I am not sure we absolutely need that explicit control.


Unfortunately your comments were hard to find. I’m not sure where the best place is to comment but so far everyone is adding them here… so that others can respond.

I added some more comments there. Hopefully everyone will be able to find them.

I’m not sure what the technical name of the controls are, but so far it seems like we have suggestions for a few different controls that all do about the same thing… that is make the image get out of the way of what you are modeling.

There are more incoming comments and requests in the discourse thread JB linked to-



This seems to be feature creeping to be way more complicated than it needs to be…To my eye, I see the only needed additions to picture frame are:

  1. automatic organization of picture frame items (master picture frame layer with sub layers for additional images)
  2. ability to turn edges off for printing
  3. grey scale
  4. ability to turn off images for printing (arguably already there with hide/show in the layer stack)

what am I missing?

  • 1to1 scaling when placing the bitmap
  • Self-Illumination control in the material UI
  • Transparency control in the material UI
  • Display behind (may not be needed)
  • Show in one view only (may not be needed)

@bobmcneel Here’s what it would take to replace the background bitmap with a picture frame implementation. I’m assuming that you would run the BackgroundBitmap command and get a picture frame object that is similar in functionality for tracing. This would be something like:

  1. Create PictureFrame
  2. SendToBack
  3. Lock (maybe)

Only Visible in One Viewport
This is really a general issue that has been requested for all object types (the ability to have objects only visible in specified viewports.) Technically the functionality already exists; it is a matter of figuring out a user interface to make this work in a way that doesn’t make you insane. I would rate the UI part as a significant amount of work because an obvious solution isn’t coming to mind.
All that said, I’m not sure that single viewport visibility is really needed for picture frame replacement of background bitmap.

Edges Show on Picture Frames

Not drawing edges for picture frames is technically very easy for Jeff or me to implement (< 1 hour). If we always want to not draw edges, this is simple. If we sometimes do not draw edges, then this becomes a user interface issue that we would need to figure out.

Always in back The display order commands would need to be tuned up to handle things like picture frames. Turning this feature on is not technically difficult. The technical difficult part is figuring out what to do if the user tweaks the picture frame so it becomes non-planar.

Grayscale, Filter

Converting an image to grayscale is technically not difficult. If the BackgroundBitmap command handled the grayscale, it could just convert the image before a picture frame was added. If we wanted to turn gray on/off, we would need to add something to the user interface. Filter is also something we probably don’t have exposed in the user interface. Probably something along the lines of what @andy proposed in his initial reply.

Don’t Render

BackgroundBitmaps don’t render. For users to do this with PictureFrames, they would need to run the Hide command. That seems like a more obvious solution than coming up with some weird special case.

1 To 1 Scale

Adding this as an option to the PictureFrame command should be technically simple.

Other Things to Consider

If BackgroundBitmap were removed…

  1. Would need to remove the option to print this from the print dialog
  2. What I wrote about above doesn’t work if you wanted to run BackgroundBitmap a second time and expect to be able to tweak things
  3. This affects training and documentation (may not be a bad thing)

transparency is already implemented in teh material UI
1-1 would be an add
self illumination is already implemented as enable diffuse lighting in teh advanced tab? (is this correct?)
display behind is not needed as you can set this interactively by where it’s placed in the scene
show in one view is IMO mnot needed since it can only face one direction at a time, it will only show up in one view unless it placed at a non world axis angle- in that case it would be fair to assume that the user wanted it ot be seen in more then one viewport-

This is already in the BackgroundBitmap UI and in the material UI. It is just difficult to find in the material UI.

That is why I was suggesting a new material UI for image objects. I was hoping to get some feedback from @andy on this idea.

If we are going to impact documentation, why not change the command name so that is better matches reality? This seems like something @mary and @margaret should comment on.

I have already moved the User’s Guide tutorial about tracing images to using PictureFrame instead of BackgroundBitmap. Somewhere along the way, Pascal suggested a name that included the word “image.” I thought this was a good name, but now I can’t remember it. For the simple example in the User’s Guide, I’ll bet just swapping out the command name will do the trick.

@margaret, did you get a chance to look at this version of the prototype documentation for a new command, ImagePlane.