Not finding a display mode that’ll implement both. On my installation, Render has no silhouette option, and Technical has both but setting it to AO has no effect.
What exactly are you expecting to happen by just turning on AO in a technical mode? The lighting scheme specifies where the source of the light(s) come(s) from. However, the source of a light also determines the source for where/how to generate shadows…and I’m guessing that’s what you’re really after here.
Ambient Occlusion is a “shadowing effect”, and thus requires that “Shadows” be turned on for the indicated display mode. I suppose we could force shadows to be on if/when AO lighting is selected, which IMO makes sense, because without it, the term “AO” doesn’t really work does it.
For now, I would just make sure that shadows are on for your given technical mode…and see if it gives you what you’re after… Here is an example of what I get when selecting AO lighting scheme, and turning shadows ON for my built-in Technical mode…
Is this what you’re after?
(fyi @John_Brock)
-Jeff
1 Like
Thanks for the clarification, Jeff.
And for recognizing the ambiguity. Might say it’s a shadowing effect masquerading as a lighting effect, but now that I’m clear I hope to remember that shadows have to be enabled. As I recall I hit this before and figured that out. It’s an excellent effect for illustration.
What you show is close to what I’m after, though I’m after line weights of creases suppressed. I can figure that out, but there are two anomalies to report.
- When I turn on “Printdisplay” to view the lineweight differentiation (between sillhouettes and other lines), it displays that in ALL viewports, not just the detail view in which the display mode is set for it. (But it only prints it in the one it’s applied to. So I suppose it’s workable, if misleading.)
Less workable, though is
- The way the differentiated lines in Technical view are printing. (I’ve zoomed into the pdf 3x for clarity, but it’s quite visible at 1:1) I’ll call it “combing” for now. I’m guessing it’s a limitation to the relationship between the mesh resolution and the pixel size (3.5) of the silhouette lines. It’d be great to know how to manage it.:
Open to suggestions about this. It looks pretty buggy…
What’s more is that in another Technical View Mode in another project adjusted to render with AO and thick silhouette lines, the thick contours appear on edges that are not silhouettes in the image below (and some sillhouettes are rendered with the thinner lineweight, and the AO has an unwanted corduroy effect on all shadow settings.
I don’t think this is working correctly here.
Please attach a 3dm file and the required Display mode files here so that we can try to repeat. Step by step instructions would also help a lot.
Could you also paste the text from Help -> System Information...?
Thanks,
-David
Thanks David. I have uploaded the files, including system information.
This is a priority issue for me.
AO artifacting and Silhouettes at Creases Steps
In terms of step by step instructions for the AO artifacting and Silhouettes at Creases. (the View Mode I sent is set thusly):
Options>View>DisplayModes>CopyTechnical
DisplayModes>CopyofTEchnical>DisplayMOdeOptions<uncheckShowCurvers,ShowHiddenLines,ShowEdges;CHooseLightingMethod>AmbientOCclusion;AmbientColor>Black.
…Objects>Lines>SilhouetteLineWidth>3
There is no silhouette around the all of the contours of the table legs. In some places the contour line is the default width of 1. Some of the creases incorrectly are drawn at the width of 3. AO contains vertical striping.
This is visible in Print Preview as well as in a print. The viewport showing the issue is identified in red on the uploaded file.
Note
This doesn’t address the combing issue mentioned early last week at the beginning of the post. I will upload a separate file containing related files.
I’ve just sent a link regarding the Combing issue from early last week. It’s an issue for printing the perspective view on that page.
Combing lines Steps
Use same View Mode created above.
Lines print (cutepdf) with artifacting at regular intervals: Webbed flanges with an arced profile perpendicular to the direction of the lines, as shown in the image at the top of this post and in the uploaded pdf.
As with the iissue in the above post, some creases are drawn with the silhouette thickness (most noticeable at the center corner of the base.)
It would be a great help if this is resolved today before I need to continue on these projects tomorrow.
I’m sorry but that just isn’t realistic.
Once the problem has been identified and an approach determined, the developer will work it into their priorities and do the development work. Then it will go to testing and will eventually be released in the normal service release cycle. It’s certainly possible that they could get you an early, pre-release build but that won’t be until after we have tested a future fix internally.
That process takes a lot longer than overnight.
Of course John, I appreciate that. A quick Rhino build in response to a bug I’ve found has never occurred to me.
I look for resolution - not bug-fixing - today at least on the combing issue because i identified it about a week ago and to that issue the teams’ \response was unusually slow, coming as it did only today. I don’t like to draw your attention to that delay, but I do so because it’s part of why I’ve felt it necessary to identify the urgency of a few support requests today.
The typical expedient resolution of your teams’ support doesn’t result in a bug fix: They a) help determine whether issues are a bug or user error, and offer support in b) the establishment of a workaround or affirmation that there isn’t one. That’s my goal.
I do all I can to find fixes with searches on line and on the forum before I post. After 10 months learning,
I’ve moved into a professional realm with Rhino. I hope that results in as little urgency as possible, but today’s is genuine.
Thanks to you and your team for continued fine work.