Render - I’m mixed about this being off by default, I have used these as backgrounds out of windows before for instance. Students also have used PFs for reflections. I’m wondering if we would have reflection and refraction ray control here as well.
Always behind - I’d say on by default… I always use these for tracing myself.
A new Image material type - What would this material type be used for other than ImagePlanes? It seems like it’s adding complexity and possible confusion to the material templates. Does it just give us a new settings panel to work in versus the basic mat>color texture? Maybe it’s a good thing… I’m just trying to figure out what it would look like and how it would be used.
Greyscale - This should be possible already through PictureFrame>material>color texture>output adjustment. It doesn’t work however in testing here in the v6 botd (bug? or by design?). Default should be off.
Self illumination - This should be set to 1 or the middle of a slider by default. It would be great if values above 1 blended the ImagePlane texture with an emitter for use with Cycles once that’s online. Think screens on electronics that cast light!
Hi Bob - my $.02
Render On/Off – if this becomes a general property for objects,(which might be very handy) then I don’t think it matters as much what the default is. If not, if the setting is for PFs only, then I think I would let these render by default.
Always Behind - tough to say what the default should be. My vibe of the moment is not always behind. People use PF now for BackgroundBitmap and I am not aware of any requests to shove it to the background, even though this might be a useful thing to add.
Grayscale - I would say not by default. It will cover more cases.
Self illumination is needed. I would set this on by default. A slider would be nice too, but less crucial.
Also, I suppose it should be possible to display with no edges or isocurves at all. (Easily, I mean, without needing to dig into display modes)
Related to the discussion of whether these should render or be on in the rendered mode check out this users file… They are having all sorts of issues with display and crashes, all due to their GPU I believe but I post it here just as an example of how someone is using PF now for making planar surfaces with textures on them in one step for visualization… We should probably keep this workflow intact with IP.
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.
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:
- automatic organization of picture frame items (master picture frame layer with sub layers for additional images)
- ability to turn edges off for printing
- grey scale
- 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:
- Create PictureFrame
- 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
http://mcneel.myjetbrains.com/youtrack/issue/RH-12677 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.
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.
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…
- Would need to remove the option to print this from the print dialog
- 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
- 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.