Bye bye BackgroundBitmaps

Here is the issue as I understand it… Can PictureFrame replace BackgroundBitmap and can we remove BackgroundBitmap?

Originally BackgroundBitmap was a modeling aid and only a modeling aid, but not very good at it. PictureFrame was originally a rendering and annotation widget, but it also worked better than BackgroundBitmap as a modeling aid.

A document comparing the two commands here…

Open YouTrack issues

If we drop BackgroundBitmaps, do we need to add some of those feature to PictureFrame?

What actually needs to be changed to make PictureFrame work better

  • For modeling workflow
  • For rendering and annotation workflows

What is a good strategy?

  • A new object type?
  • More hacks to make PictureFrame work a little nicer for both use cases?
  • Add a new simple material type… called “Picture or Image” that has only a
    few controls that would be the material used when a PictureFrame is
  • Image Transparency (slider)
  • Grayscale (check box)
  • Always behind (check box)
  • Render (check box)
  • Filter ???
  • SelfIllumination ?? (check box)
  • Make these the controls on the front properties page… I guess they would need to be on the material page too.
  • When a PictureFrame is placed there should be some default settings that do not appear to the users unless they change the material type to Other.
  • SelfIllumination always on (check box)
  • AlphaTransparency always on (check box)
  • Cast Shadows off
  • Embed Bitmap

I know I’m supposed to ignore this - but I like the idea of a “Picture” material type that only has controls for “Self-luminance”, “Greyscale” and “Alpha transparency”

It would hide some of the more esoteric controls like “Use diffuse lighting” and the “Use color texture alpha channel for transparency” control (draft name!) that I’m planning to add. Greyscale is already possible using the current system, but this would make it even easier to achieve.

I’m not sure about “always behind” being a material property… I’m also not sure what you mean by “Render (check box)”.

One thing though - you mentioned making these controls “front page properties” - how about, instead of repeating all of the controls, we make it so that the page that shows up by default for pictures frames is the material page (the same way the light page shows up for lights)?

  • Andy

The options listed were based on the combined features of BackgroundBitmap and PictureFrame.

For example, the “Render” checkbox is on the list because BackgroundBitmaps don’t render and PictureFrames do. Depending on the use case, modeling vs rendering, a user might want them to render or not. Always behind is a similar issue.

Also, I’m suggesting that these options might need to be on the top level Properties tab rather than on the Materials tab.

What is with the name “PictureFrame”? There is no “Frame” involved.

Shouldn’t this be called “Image”?

Hey Bob-
Just following up on our conversation about Background bitmap vs pic frame-

In my opinion, BB can go away - Side by side they are as follows:

Bb only aligns with x axis- pic frame is user adjustable (and much more useable)
bb- only one image in the frame per view port- PF as many as you want
BB has grey scale option- this is the only possible add to PF
Bb does not print ever- PF can be set to not print simply by hiding it, layering it etc, bit can print if you want it to.
Bb does not support alpha transparency PF does
BB does not support embed
Bb cannot be gumball edited
Bb cannot specify self illumination
BB cannot be used for rendering (simulated computer display for example)

After reviewing the help files and playing with all the options, I honestly can’t think of a scenario where BB would be preferable over picture frame…it’s a total pain in the ass to use, especially if you have to edit it or turn it on or off…not to mention that you can’t dim the image, you have to do that in an external editor.

Since it’s your name on the door, I say pull rank and order it killed. With tools, be great or be gone, and BB is far from great.

My .02-

This is a two part question…

  1. Can BB go away? Answer seems that it could.
  2. How can we improve PF so that it better servers users? Can we ignore all the features, wishes, and bugs on BB? Or, could we make sure that PF is a more perfect tool (plus easier to learn and use)?

The 1To1 option in the BackgroundBitmap command is missing in the PictureFrame command.

Users would like a scanned image to be placed in the model with its real size. This was why the 1To1 option added to the BackgroundBitmap command.

A Scale setting is also needed in the Pictureframe properties.

Why don’t Rhino’s standard Scale commands or the Gumball work for this? Do we need another command?

I have no idea how this could be useful. Where would you get an image that 1to1 matches the physical world?

I’ve updated this document to include the Help reference for a new command to replace both BB and PF. See the last section.

I’m thinking the Scale option more like the Layout:Model scaling when you enable a detail view.

The problem with the Scale command and Gumball is they don’t keep the original size. This can be an object property instead of adding a new command.

Scanners, including large format scanner, can do this.

These are the original bugtrack items that were the catalyst for the feature:

The last item was a request from Adidas.

The 1To1 option was requested by an Adidas factory.

In their workflow, they scan real size paper cuttings or drawings on papers. Place the scanned image as a background bitmap. The 1To1 option uses the dpi information to calculate the size in the model space.

@bobmcneel I was too picky about adding the scale setting in properties. Gumball and the Scale commands would work just fine. Please only make sure the 1To1 option will be implemented.

Shouldn’t this be called “Image”?

ImagePlane… ?


Should it be an object property on all objects then?

So far the idea is that this is a normal Rhino surface with a special material UI. All the other properties could show up on all objects.

Ok, I understand this now. 1to1 is needed when someone places a scanned image of a drawing in the model or layout.

That was not a use case I had thought of.

Works for me…

I’ve updated the prototype Help for the new command at the end of this document.

Hopefully it reflects everyone’s feedback.

Here is an nearly final version of the prototype documentation for a new command, ImagePlane.

There are some highlighted questions. Please comment everyone… including: @margaret, @theoutside, @BrianJ, @pascal, @mary