Rhino 6 woes: I HATE the picture command ... Please don't phase out background bitmap function

Its my understanding that all those attributes can be applied by users on a per object basis.

But your missing the point which is it is possible for users of either command to get along without it, but users are going to be inconvenienced if the command they use is removed.

The thing that annoys me the most is the claim that every effort was made to make this work like BackgroundBitmap. I see no evidence that any effort was made. My guess is that whoever worked on this did mot even bother to find out how BackgroundBitmap works.

To make a command that works like BackgroundBitmap it should allow the image to be assigned to a viewport so that it is not visible in other viewports. The image should be in the background and it should be locked except when inside the command where the edit controls are available. The claim that users can lock the picture object themselves is just an accident waiting to happen and there are already way too many booby traps in Rhino.

2 Likes

I suppose we could go ahead and spend a lot of time searching for the discussions around this matter. I know I won’t. I do know, though, that there were long discussions going on. But then, the customer is always right and reserves the right to come back years later and complain…

While i was aware of Serengeti. My workflow is so jammed packed i had no time to try the beta. I was not even aware Rhino 6 had dropped until a week or so ago. As i teach at annual conference and we are looking to licence our lab PC’s for 2019, I downloaded 6 to make sure i was familiar with it’s quirks before next year… Most version updates have been fairly seamless for me… nothing but better. This was the first time I ran in to a serious problem with the update.

I am super impressed with the improvements to the built in renderer BTW…

-Brian

1 Like

Becarnes,
you captured the issue entirely.
I use the background bitmap frequently and in exactly the same way.
-Paul

2 Likes

We haven’t used the BG bitmap feature here in years, so we probably won’t miss it. Until we do…

We’ve relied on the use of Picturframes extensively in our presentation drawings to combine renderings, hidden line drawings, and 2d CAD views. We’re experimenting with the Rhino6RC1 and have seen issues with many of our Rhino5 drawings. In over half of them, the Pictureframe textures just don’t display. Blank surface. They show up as a “surface” and the bitmap is still assigned under the color entry, but it doesn’t show up, even if I reassign the bitmap. Unfortunately, it’s really random. some work and some don’t. Can’t figure out what’s causing it.

I can fix it by changing the material type to “Picture” and assigning the bitmap again, so there’s a workaround. It would be nice if it just worked.

To me these are different functions:

one is used to add pictures into a model environment

the other is used to replicate the mechanical drafting days function of laying a drawing underneath your work environment to inform your new build…eg the BB is not part of the model, just informs it like the grid.

I’m honestly not a big fan of trying to jam them together, but i can see the perspective of trying to add features to BB making more sense by combining it with a similar function.

Hopefully this leads to things working better if nothing else …

-b

@James can you please send me the Rhino 5 models that you’re using? Please also include the images that are attached to the PictureFrames. It appears there’s a bug reading those files and getting them to work in V6 - a bug I want to make sure we fix.

Yep, that’s pretty clear. Right now we’re trying to determine what the best course of action is. Ideally we’d make everything work well for everyone - and quickly. Talking with @stevebaer it’s clear that making objects visible only in one viewport is technically difficult, and it’s a major feature people have requested for a long time (not just for Pictures).

And it’s clear that our understanding, based on previous conversations, about what people want when tracing background images is incomplete. One of the requests we got was “can we show multiple background bitmaps in the same viewport?” - that one is possible now with Picture, but was never possible with BackgroundBitmap.

I understand that it’s disappointing when things change - especially when they change in ways that aren’t in your favor. What is even more ironic is that the unification of BackgroundBitmap and Picture came under a project called “papercuts” - we were trying to remove little irritations from Rhino to make it more pleasant to use. And in that we inadvertently added some papercuts. Sigh!

1 Like

How can BackgroundBitmap be an irritation? What is irritating about having a command that allows the user to accurately position an image that always stays in the background, that is visible only in the one viewport so that it never interferes with viewing in other viewports and can never be accidentally selected or dragged???

The only irritation to users will be that none of those useful features will be available in the picture command.

And stop saying that the 2 commands have been “unified”. That implies you did something to incorporate the features of BackgroundBitmap when its obvious that you did nothing at all.

McNeel first floated the idea of eliminating BackgroundBitmap about 15 years ago and all the objections that are being raised now have been raised on numerous past occasions. Over the years, McNeel employees have been telling users the command is obsolete, but the fact remains that it is still the best way to enter data from technical or mechanical drawings into Rhino. BackgroundBitmap is efficient. Picture is not.

Well BackgroundBitMap has done that technically difficult task for 20 years. Its not obsolete - BackgroundBitmap is apparently way ahead of its times.

an observation on motive here…

I don’t want to share the more abrasive feelings that have cropped up on this thread but I do think there is a problem with how this issue was handled that could be done better.

I’ve worked in IT and with Devs for 20+ years . . .

when you put a note saying the function the user chose to use is “obsolete,” followed by a note that is in essence a threat to the user eg ‘learn the new tool because we are going to yank the one you prefer’ you are attempting to change behavior…

But as the saying goes - “saying something is so, does not make it so …” And the soft skills used in the communication of the desired behavior change are really bad.

My suggestion of organic cultural change would be something more like … you basically continue to test and add features to your replacement, If you must have a behavior changing popup, it would read. “Mcneel suggests trying the upgraded “picture” command for this function.” Then over time users would try it, and tell you what needs to be done to fix it. if Mcneel’s devs do their job right, eventually there would be no users of the original function and it would be sun-settable.

My IT impression of this issue is that there is an untold reason Mcneel wants to remove the command… Maybe it’s as simple as it lacks elegance from a coder perspective (coders are fickle folks, i know). Maybe it is more practical. At the end of the day if there were no reason to remove it, this conversation would not be occurring. Right now the closest we have to an explanation is that the devs had been asked to improve the feature (my guess, rotation and other such things or some users complaints about it that should have been using picture frame or other commands), and rather then do that, the thought was to make the issue go away by attempting to ram a square peg in a round hole and merging it to a similar, yet very different command. Transparency might help here.

Why was it a pain point?
What does Mcneel not like about the old function?
Why can’t it stay? (what won’t work if we do?)

thanks
-b

Yup that is quite likely an accurate explanation.

The sad part about that is that it is really quite easy to rotate or stretch or even remove perspective distortion from a bitmap image in Rhino. All you have to do is make a planar surface and apply the image as a texture map and then rotate or stretch or whatever and then render the image to whatever resolution you want and then use the result for BackgroundBitMap. One nice part about doing it that way is you get a clearer, crisper and more accurate image to use as a reference than if you do it with the picture command. All the code is already there to do this it would simply be a matter of assembling the steps. But I would be happy if they just left the BackgroundBitMap command alone.

So I’m not the only one that sees that it is not really the users but somebody at McNeel that does not like BackgroundBitMap.

People logged bugs about it. They wanted improvements, and many of those improvements are already in Picture.

Yep, that’s what we tried. The conversation about Picture and BackgroundBitmap has been ongoing for years, as jim mentioned. Either we didn’t listen very well during the conversation, or people didn’t chime in about what really mattered, or now that we’ve shipped more people are interested and are bringing a fresh perspective. Regardless, it’s clear that this change isn’t working for everybody. So we’re working on resolving the problem - I don’t have an answer yet.

Your passion is welcome here. It’s clear how much this matters to you by how personal you guys make it. It’s not my intention to have this change be a personal affront to you. I’m sorry you took it that way.

2 Likes

Test groups need to be diverse, but no matter how diverse they are, if we don’t listen to the murmurs in the group you risk discovering the murmur was just the tip of an iceberg in a wider release. You are right, the second things go live you are going to get way more response to any thing you changed (both good and bad)

If this has as you say been an ongoing discussion, and there has been friction or concern over the change, who’s idea was it to force it down the user’s throats? Who thought that would go well? It’s like Mcneel is saying we know some dislike this but we don’t care/don’t think it’s a real issue…

I had heard of the beta, thanks to the nice newsletters sent out by mcneel. That said, The public beta on Serengeti was not something i got to do because I don’t have time to experiment as much as I’d like and because I run a 14+ show a year schedule, often working on the road from hotels on my surface into the night. My dev backlog is longer then this thread :slight_smile:

Because our need to acquire a number of licenses for 2019, me downloading the evaluation copy was of necessity… I needed to make sure if we got the new software i would feel comfortable there. I (improperly) assumed the new version was ready for prime time and would be a pain free transition.

I’m sorry, i cant say I was aware of the older debate, because until now my feature was always there, and never threatened me by saying I’m doing it wrong and eventually will be forced to use a inferior tool.

Hopefully this thread is a positive because i need this workflow to work for me not create a headache.

-b

found this: https://discourse.mcneel.com/t/bye-bye-backgroundbitmaps/

Goodness … reading that thread it seems the “user OK” comes from mainly one user. Gotta love users who arbitrarily tell the developer it’s OK to remove a feature as if they speak for all users… While probably not the users intent this is intellectual arrogance at it’s worst and a savy dev would be well advised to take any such advice with a massive grain of salt!

Thanks for the linkage, at least i know what i missed…

I’m crossing my fingers and toes and anything else i can cross that Rhino 6 does not wreck my beautiful app

-b

As with everything in life, those who show up help make the decisions. We can’t count absent votes. And it’s nice that you’re voting now - nothing is permanent :slight_smile:

4 Likes

This is not an election … If Mcneel really wanted to know what the user base thought in that manner they could have done just that… In those emails we get, a survey could have been added?

Respectfully … you admit this was/is a contested issue
Yet the company chose to force the change with that context?

I’m at a bit of a loss… My apology to those who suggested things were worse. Apparently I missed the good fight many have already put in. Thank you for your efforts to protect a good product!

My question anwers (i think)

Why was it a pain point? (because people asked for improvemnts or reported bugs due to feature confusion)
What does Mcneel not like about the old function? (It’s apparently harder to dev/improve then picture)
Why can’t it stay? (Not answered… Probably none. In short there is no reason other then some’s belief that rhino has too many commands or perhaps because Rhino is sick of getting user requests related to it)

I’d like to humbly suggest:

  1. Keep BB, and restore it to the view menu as in 5. If you want users to know it’s not Mcneel’s preferred way add (legacy) to it …
  2. Continue to work on picture, and maybe also add it to the view drop down so we can have the option in a better place
  3. Keep making things better and more awesome! Be super skeptical to anyone who claims a feature can or should be removed. They do NOT speak for all of the user base

I’m excited that my thread at least drove discussions that lead to dev tickets to look at issues. I hope and pray that I will be able to keep making awesome things in Rhino and hope to pay more attention to the online community and improvement discussion in the future

Cheers!
Brian

An interesting debate.

Would it be possible to combine/coalesce Picture & BackgroundBitmap by adding a “Project to Background” command line option to Picture, which would create a BackgroundBitmap as a projected version of the Picture? That way you can harness the strengths of both approaches without being concerned about their respective weaknesses. It also converges very similar commands, making them easier to discover.

If anything, it would make BB stronger, as one can manipulate a Picture in ways that aren’t possible with BB in V5: Tilting the image relative to plane, point editing to correct perspective distortions etc… Then when the Project option is called, add a splash screen warning that the operation is a one-way street, so add a Delete yes/no option for the input picture.

It seems a shame to remove a tool from Rhino just because the developer can see no use for it. Irrespective of whether Mcneel garners a response to such a request on here during the development period, they have no way of knowing whether a user at some point in the future may come up with an obscure but ingenious use for this (or some other) command that wasn’t even vaguely perceived by the developer. That is one of the joys of using Rhino: The freedom it gives the user to cook up a solution to a problem by using their imagination.

1 Like

I’ve always hated backgroundbitmap. The images are always behind the object I’m drawing (I usually prefer them to be transparent and on top - otherwise I can’t see details that are behind my work when in shaded views), and I can’t composite several images together or layer images to line them up with each other, or put multiple sections of a product in 3d space at once. Or distort images. I’ve always used PictureFrame with transparency and just put them on layers that I lock, which works pretty well. Please don’t mess up pictureframe. Picture is working pretty much just like pictureframe, so the name change is fine, but if it were to function more like backgroundbitmap then it would make my life much worse. I honestly think you need to keep both commands.

1 Like

Yes!

Philip

6 Likes

Keep both. :sunglasses:

4 Likes