Cycles - Edges bleeding

@FrankS Yes, well unfortunately, that issue is going to have to remain until I can figure out a way to correctly draw wires over the top of someone else’s results. In short, I can’t know how any given renderer is going to draw a material, which means if a renderer is going treat something as “transparent”, I have no way of knowing that…Now, I understand that the material’s “transparency” is something to look at, but that’s really just a hint and not a concrete description of what the final results will be… For example: IOR may exist, and therefore, just looking at transparency would only be part of the process.

Let’s get the other issues resolved first, and then we can start looking into “guessing” at what really should be drawn. :wink:

Here are the issues I’m currently tracking down that seem to cause bleeding…

  1. Locked layers
  2. Your custom surfaces
  3. Texture mapped surfaces with “Alpha transparency” checked.

The first two have workarounds…

  1. Simply unlock the layers…

  2. This one is a bit more involved, but has to do with “Picture Frame” objects. Apparently your custom people objects are really just picture frame objects that you’ve trimmed…The issue is that Rhino still sees them as “Picture Frame” objects, and thus they undergo special processing inside the pipeline…that special processing is what is causing issues in Raytraced modes. The workaround is to strip the objects of their “Picture Frame” status…To do this, select all of your custom objects, then run “Export Selected”. When the dialog box pops up, make sure you UNCHECK the option “Save plugin data”, then save them out to some file. Now either delete or hide all of your custom people objects and import the file you just exported. That will bring back all of your custom objects, but as standard trimmed surfaces and not as “Picture Frames”… However, now that they’re no longer a picture frame, all of their isos and edges will display… So you need to select all of them and use “SetObjectDisplayMode” and set them to use a display mode that does not show wires… I’ve provided a “RenderedNoWires” mode here for you to start with… This will make your people objects look and function exactly as they did before (in any display mode), but will eliminate the bleeding in Raytraced mode.

  3. This issue has no workaround (so far) but I’m looking into it and will let you know.

Let me know if you have any questions about #2 above… I’m not sure if my instructions will be clear enough.

Thanks,
-Jeff
RenderedNoWires.ini (11.3 KB)

@pascal
How about a command like ConvertExtrusion Explode blocks and the like for PictureFrames?
Maybe name it ConvertPictureframe with options to keep display mode or not…

-Willem

@Willem Sure… it may be that there is something like that already… I just don’t know…and the procedure I described above is the only way I know of atm to do this… Picture Frames simply have an internal user data tag hung off of them… and there may be some command(s) that exist today that allow you to strip user data directly from selected objects… I will check.

Thanks,
-Jeff

I think it’s best to have a straightforward way to convert PictureFrames with a dedicated command. Anything else will never reach the masses.

@jeff Not critical on your workaround suggestions, just an observation that the PF lack means to convert them.

-Willem

@jeff

Thanks for the detailed description!

I didn’t know _pictureframe objects represent a special category. For me pictureframes were simply a surface with a self-illumination texture, with a _setObjectDidplayModes attribute to make sure the display settings override the viewport specific settings.
To identify an obejcts nature of being, I consult the properties window. When I select a “pictureframe”, it says: “Surface”. Maybe this information should be more specific, as I had no idea pictureframe was a catagory.

Anyhow, I am glad to have learned something to help us work around the bleeding glitch in this scenario.
I will let you know if I find more bugs, related to this topic here.

Thanks again,
Frank

RH-42859 is fixed in the latest Service Release Candidate