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.
I have no idea why we are moving away from PictureFrame as a name. Those two works are ordinary works. Image & Plane are both geeky words. Do you go out with your camera to take some images? What do you put on your wall - āplanesā ? If anything, I would ditch the āFrameā part and just call it āPictureā - in the same way that a curve is a curve, and a surface is a surface.
My first suggestion was āImageā.
I guess I donāt think of a drawing, site map, or sketch as picture.
I do. For me, an image is something much more technical. It always has to have something to do with optics.
Iām going to agree with Andy on this one. Just checked and Word uses the term Picture
Also - the question of whether it should render by default - and printā¦I say yes. It should do both. Because if something renders or prints and the user decides they donāt want it, they will think āhow do I turn this offā. If something fails to render or print, they will think āthis is brokenā.
Having per-object āRenderā and āPrintā properties would be an excellent way to solve this. They would be very easy to implement, and would be a very useful feature.
And hiding them is not the same - because then they donāt show in the display either - which is the point. You want them to display, but not get output.
I have always found this to be a lack with detail viewport edges. I donāt want them to print, but I want to see them in the viewport.
- Andy
Incidently, the āPictureā material type is in process. We should have something checked into V6 pretty soon. I think its a good idea even without the change to PictureFrame.
Yes - this is correct. Thatās actually exactly the reason it was added.
Implementing āalways at the backā is going to be tricky for renderers.
The fact that PictureFrame in V5 shows edges is, in my opinion, a bug. It did not do this in V4. The imlementation is different - and in V4 it is, in my opinion, more pure.
In V4 the PictureFrame command sets the display mode for the object to be āRenderedā. V5 has a āhackā that causes āspecialā objects (created by the Pictureframe command) to have specific display mode attributes that replicated the default rendered mode. But this seems to - for some reason - include isocurves and edges. I donāt think these should appear under any circumstances.
In other words the discussion about setting isocurves to -1 by default is moot. They shouldnāt show at all because they should display as if they are in rendered mode. ie - no wires at all.
Basically, I see no reason why all of this shouldnāt be just added to the picture frame command, and the UI carefully honed along the lines of what Iāve been doing with the new material UI.
Picture is fine with meā¦ it was the "frameā bit that seemed most confusing.
Thanks Andy, That was the main feedback I was looking for. I could not come up with a better way to cleanup the UI.
Good, I thought there might be some major technical reason that I didnāt understand. Iāll make sure this is written up as a bug. Who can fix this?
Iām not sure how important this is.
Also, I donāt know where it would be in the UI. @stevebaer suggested that MoveToBack should work on Picturesā¦ and any other planer objectā¦ some work involved.
Who can fix this?
Jeff
Nor am I - I doubt anyone will want to do this. But it will be case where it looks different in the UI than in the rendering.