I have been using rhino since version 2 and I majorly use the background bitmap function when fabricating models based on historical subjects. Up till Rhino 5 it’s one of the strongest features to me producing a fast model for a client.
I can literally grab a plan for a ship such as this from the US navy’s ONI reference book and build what the client wants…
So imagine my surprise to find the feature missing from my viewport drop downs. A quick search in the docs reveals it’s still there but I can’t seem to find it unless i manually key the command. Even worse Rhino now explains that they have decided a highly used feature of mine is “obsolete” because of the picture command…
So I’ve tried the picture command… and i get what the devs are going for… the perspective view render is neat and for some models where i’d love to have banners and 3d objects have the needed art i could see it as neat, but for reference fabricating it’s beyond awful…
I wanted to fab up a basic human form as an underlay for a project… so i grabed a quick human form from the web to serve as a reference to keep me grounded.
So I want it to be passively in the background with the grid overtop so i can build over it. I do not want it to move once i have it in place.
i do NOT want it to be interactive or drag-able unless i am setting it in place… I keep dragging it by accident. I also need to be able to hide the image at will and i need it to actually be in the background so i can still see/use the grid…
I guess i could throw the stupid pictures on a separate layer and lock it (tried this and it sort of works) but that is stupidly complicated for what was a basic function.
And i have no idea how to view my grid with this nonsense, and it also would be helpful if the perspective version had the option of opacity, or to turn off the pictures for the perspective view.
I keep poking around but this feature is in my way not helping me.
Am i doing something wrong? Is there extra depth to this command? when is the background bitmap command being removed?
that’s an idea… but now the new software is inferior to the previous version … I now have to spend oodles of time setting up somthing that worked without issue before. why would they remove the feature?
Hello - Picture objects get their own materials with the image as a texture in V6 - they do not use the layer material. Edit the material per object - you can select multiple planes and edit the transparency on all at once.
The one functionality that is not covered by Picture is the ability to show or hide a background bitmap in a particular viewport. A picture(frame) is either visible in all modeling viewports or it is not in any.
For that reason the BackgroundBitmap command needs to be retained, and there should be some kind of easier access in the standard workspace other than having to type a non-autocompleting command.
Yes, background bitmaps can be applied to multiple viewports. That means you can have background bitmaps from several different views at once without the different images interfering with each other.
And transparency is not a good substitute. McNeel also tried that with the grid. A transparent grid is not as useful as a background grid. The same with images. A background image is a better reference. A transparent image just shows you what its like to have cataracts.
I’m thrilled to have all your feedback about this command. The Picture command was designed to replace the BackgroundBitmap command, and we’ve been discussing it quite a lot over the last couple years on Serengeti. It’s clear that some of the improvements we made (making multiple pictures available in the same viewport) is a feature to some, and a bug to others.
If I summarize what I’m hearing, the primary problems introduced by Picture are:
It’s not on the menu (was View > Background Bitmap and is now Surface > Plane > Picture)
It’s not possible to have one picture per viewport, as you could in Rhino 5
The Picture object obscures the grid
By default, the picture is movable because it’s an object - you have to lock it manually to keep it stationary (either by locking the object with the Lock command, or locking the layer it is on).
1 is big… I like the organization of background bitmap being on the view… options… to me my use of Background bitmap was not as a object in my model, but as a reference to the view… akin to tracing paper from my drafting days (sorry, dating myself) as the bacground image may be full of clutter i’m focusing around in the 3 views, seeing the pic in perspective is more in the way then anything else.
I like the picture feature as an additional feature… I have my trade show booth “kit” modeled in Rhino and being able to insert my banner art on surfaces easily would be helpfull there. In that case i totally would want to see the pictures in perspective. But historically that is not how or why i was using background bitmap.
Typically If I’m working off 3 view or historical plans i load the corresponding part of the drawing into each view. carefully scale it to the needed size and work away… I don’t really need them to show in perspective… and as i usually use the same image (3view sheet for example)
I have page scans of a reference book… I don’t want to take the time to trim what i need so i load the same image in different views and scale the needed piece/view to size.
and I am constantly hiding and reshowing the image as i work…
yes this… if i am building over something i want my grid visible…
as many of the plans i use are white or “yellowed” from age the only issue i ever had is the brightness combines with the lousy overthick lines on the reference drawings sometimes had a obscuring effect.
4 yes… if it’s a reference i don’t want it to move after i scale it and place it
So another function i used was the scale. My end model is in a set scale so if i know that size what i’ll do is use the scale and mark a point on the image then drop the drawing to the right size. I believe i can still do that but without screwing with the opacity so i can see the grid it’s hard. On the other hand if it’s handled as a surface i assume i can rotate it? Scans of admiralty drawings are often not 100% straight so if i could rotate it it might be a help.
Again, I can replicate most of what i need but it’s work to do compared to what was a fast and powerful tool
As far as I know, that was always possible in V5 with PictureFrame.
Of all the things you mentioned, #2 (and perhaps #3) are the most important. Those are what Picture can’t do.
Picture(Frames) are far easier to adjust (scale, move, etc) than background bit maps - you can’t even rotate a bb if I remember correctly. Plus, you can actually stretch or distort a Picture by pulling control points if you need to compensate for a scan/print of an image or drawing - there is often some stretch or distortion introduced due to the printing process. I often have to adjust aerial photos to match site plans for example.
You can also trim images, use an alpha channel with a png to create transparent line drawings etc. I always put each on its own layer that I can turn on or off and lock - no big deal once the picture is correctly placed and adjusted.
I always thought that Picture was just another one of those attempts to combine two “similar” commands into one - the problem being that they are not similar enough so that all functionality from both can be retained.
I thought Picture replaced the PictureFrame command.
If its supposed to be a replacement for BackgroundBitmap then why doesn’t Picture stay in the background? Making the Picture transparent is not a good substitute for having the image in the background.
A BackgroundBitmap exists in only one viewport. That’s a feature that allows you to set up different different views at different view angles. Suppose you have 2 views 30 degrees apart , With BackgroundBitmap you can setup 2 viewports each with its own BackgroundBitmap,
Both images can be visible in their own dedicated viewport at the same time but don’t interfere with viewing in any other viewport.
It obscures geometry also
BackgroundBitmaps are clearer than Picture images. There has been some improvement in this in Rhino6, but the images are still more blurry than the original. In V5 PictureFrame images were often so blurry they were not usable.
Picture was the PictureFrame command, and we tried to make it similar enough to BackgroundBitmap that we could have one feature instead of two. There were lots of feature requests for BackgroundBitmap that Picture already solved: improved rotation and scaling being among them.
Clearly we didn’t solve the problem perfectly for everyone, and we can probably fix it.
A BackgroundBitmap exists in only one viewport: Logged as RH-43723.
The Picture object obscures the grid: Logged as RH-43725.
BackgroundBitmap isn’t on the menu: Logged as RH-43724.
BackgroundBitmaps are clearer than Picture images: Logged as RH-43726.
This is a double-edged sword. Picture objects are real objects (in fact, they’re just textured planes). This makes them transformable and editable, and can be placed in 3D space. Yes, that’s also what makes them movable inadvertently just like other objects - and that’s why Lock has existed in Rhino since 1.0. Unless we go all the way back to BackgroundBitmap objects, we can’t fix this one.
It seems like figuring out how to solve the first two bugs, above, as @helvetosaur suggested, is probably the best course of action. I think the image crispness is usable as it is in V6, using the images I’ve tested with. If you have other examples of images that don’t work well with Picture, please let me know.
If duplication of functionality is the issue that’s being addressed then McNeel should get rid of the Picture command. That command adds nothing that users can’t already do for themselves by creating a planar surface and applying a texturemap, transparency and rotations, trimming etc etc.
BackgroundBitmap is the command that has unique useful features that will be lost if its removed.
This is not quite true - a Picture(Frame) object has a special material applied that shows up the same no matter what display mode the viewport is in; it also has special lighting characteristics, there is no shadowing, it ignores the lights in the scene (it is self-illuminated) and thus looks the same no matter what angle it is viewed from. So it cannot be simply replaced by throwing a texture on a plane.
PictureFrame has been around since V4, in my mind the only real change with Picture was the shortening of the name… Some of the options have indeed changed - in Picture we got a couple more command line options for placement, but there were also some other options from PictureFrame that were removed…
PictureFrame (V5): Command: PictureFrame First corner of picture frame ( Vertical SelfIllumination=Yes EmbedBitmap=Yes AutoName=No AlphaTransparency=Yes ):
Picture (V6) Command: Picture First corner of picture ( 3Point Vertical Center AroundCurve 1to1 )
