Display mode for picture surfaces

I have some surfaces that started out as ‘picture’ which I then traced off a shape and trimmed.

Changing the object material to ‘Use Layer Material’ is pretty straightforward but the surfaces are still rendering when the viewport is set to wireframe or whatever other mode.

SetObjectDisplayMode doesn’t seem to be of any help?

How do I convert a ‘picture’ to just standard vanilla geometry like any other surface? Obviously I can remake the surface but I have quite a lot to do and was hoping there is something I can select all and one click to make them forget they used to be pictures.

It doesn’t look like there’s a command, it could probably be scripted up…

If you haven’t manipulated the surfaces in 3D (i.e. they’re still planar) you can just DupBorder them all, then PlanarSrf the result and delete the original Picture objects.

If you try changing the surface material from the image to anything else you end up with a “screwed up” object that doesn’t respect layer colours and displays a material in wireframe. I thought this had been reported as a bug, but I can’t find the thread.

Same issue in the Beta.

1 Like

Thanks guys!

At least the good news is I didn’t miss something obvious.

I just tried that here and it is interesting.

  • Opened a new file, with just one layer (default) and made the layer material “Paint” and the color red.

  • Put the viewport in Rendered mode.

  • Inserted a picture, then selected it and in the material tab in Properties, in the top dropdown where it shows a thumbnail of the image and the name, click the down arow and change to “Layer material”

  • The image disappears and is replaced by a solid red surface.

  • However, the surface stays rendered no mater what viewport display mode is used.

So, something is telling Rhino that this is still a material that should display independent of what the viewport display mode is. I think that is determined by the object attribute IsPictureFrame being set to True. Unfortunately, that attribute is read-only, so I can’t set it to False via a script.

1 Like

Yeah - Pictures are special objects, for better or for worse, with some user data attached someplace so they do not behave like regular surfaces with images.

@wynott - see if this script does anything you like -

ConvertPictures.py (955 Bytes)

To use the Python script use RunPythonScript, or a macro:

_-RunPythonScript "Full path to py file inside double-quotes"

-Pascal

What happens if you (after trimming the surface) just change the Material Type from Picture to PbR or Plaster or Paint?

nothing, because the actual surface itself is tagged with an attribute that makes it a “picture” as opposed to a “surface” and that attribute makes it stay a "picture object " no matter what you do to it.

as pascal mentioned above, at the moment, this particular attribute cannot be changed.

Interesting news.
If a picture surface knows it’s a picture, maybe there’s a way to make it participate in draw order, especially in layouts. They don’t, but they should.
Thanks!

2 Likes

Hi all,

Below is a script which will take all selected picture objects and replace them with normal surfaces. It is not limited to planar surfaces, so even if you have deformed a Picture object, it should still work.

Edit - revised version - retains layer, color and other attributes from the original picture object.
(I hate Discourse’s treatment of same-named files, if you update it doesn’t always work…)
PictureKiller.py (1.5 KB)

prove me wrong if i think that adding picture object was not properly thought and was ad hoc addition resulting in few improperities down the line. like no draw order or inconsistency when changing material type. there is no rationale behind why pictures should be irrevirsibly pictures. maybe changing material color should just break that special tag and continue being surface.

1 Like

Is this really all that dramatic? The PictureFrame object was added in V3 (IIRC). Maybe even before we had draw order commands available. So yes, there could be some more improvements made, notably to have them obey draw order. I think that one has been on the list for quite awhile - as many other things have. There are at least two easy workarounds posted above to making them back into normal surfaces.

I for one am amazed at what you can do with Picture objects - bend them, stretch them, cut holes in them or even slice them into a bunch of smaller pieces.

1 Like

Hello- draw order works on curves, text, annotations & hatches

-Pascal

There are these YouTrack items:

https://mcneel.myjetbrains.com/youtrack/issue/RH-18266/Draw-order-commands-should-support-surfaces

https://mcneel.myjetbrains.com/youtrack/issue/RH-58698/Image-draw-order-issue

https://mcneel.myjetbrains.com/youtrack/issue/RH-12677/PictureFrame-Does-not-Obey-Display-Level-Commands

All “Future”…

I added one more directly under the Picture category…

https://mcneel.myjetbrains.com/youtrack/issue/RH-77690/Picture-objects-should-be-included-in-display-order

1 Like

yeah i solved my issue last week just moving the picture below in Z. i understand it is kind of consistent that it does not participate in draworder but maybe it could :slight_smile: espiecially when its picture. i usually deal with orthophoto images underlying my situational plans.

Funny: just found out it’s possible to move things in Z also in Layout space (using BoxEdit), which actually solves the draw order issue!
Not totally straightforward to figure, though…

This even works for any 3d object placed directly into Layouts (which is possible).

1 Like