One) I thought it best if you generated the Plan View on your system for testing purposes. But I’ll upload another one with one I generated. The difference is there on my system when I generate one. Here’s a snapshot. It’s the door in this shot. (Wireframe Top-Ground View, Model below, Plan View outlined in green above):
On another version of this project the door became the matching lineweight if I exploded the Plan View, but that doesn’t fix it in this version for some reason.
Three) Please let me know how best to print with a larger default line thickness so I can work around the above problem (unless we can fix it). This adjustment (in Print Setup) doesn’t have any effect on Line Widths printed from a Plan View) no matter which of the setting options shown are changed.:
@djhg I see the issue now! It looks like a bug when printing objects in section (in Wireframe it doesn’t print the door in the right line width. In Hidden there is a mixture of line widths.)
I’ll get back to this post when we fix that.
What you can do while we fix this is to create a plan view (vaPlanView command) or Section View (vaSectionView command), and print them rather than the 3D model in section.
That’s where the problem I am asking about is, Francesc. With Plan Views and Section Views. I guess I haven’t explained clearly enough - though I thought i had - that it’s those views vaPLanView and vaSectionView that don’t display line widths at the moment. (And the Views of the Model have unworkable problems which I appreciate you acknowledge.) This is why I keep asking how to adjust the default line widths for vaArq objects, because if that’s not available, given the other limitations, everything from VisualArq used as a documentation tool has to have the ulttra-fine default width.
Try to explode the vaPlanViews and vaSectionViews and print them in Wireframe display mode while we fix these issues. Those objects that had the linewidth set to “Default” should take the “default line width” from printing settings.
I keep trying this, but it has only worked one time.
Does this work for you with Plan Views, Francesc? Even if exploded? Consistently? On my system it only works consistently on curves created in Rhino but, as I have said, it has never worked on the many lines which are generated in a Va Plan View yet retain the default line width irrespective of their settings. That is why I have asked if there is another way. If that is the only way to do this, then - at least on my system, which is quite new - the factory default Rhino linewidth is unfortunately VisualArq’s only reliable line width.
Every object exploded has its linewidth set by object to “default,” and Wall fills all become black also. My tests with the Savoie model, 2 versions of Va ago, the line widths were restored when exploded, but those projects now explode to default linewidths. Maybe this has been lost with recent revisions. It’s a significant loss.
Today it’s working for me also.
Thanks…
It may be that the multi-step activation of PrintDisplay (S>Enter>O>Enter>Enter) isn’t getting fully activated and the Print Setup > Linetypes and Line Widths > was set to Match Viewport.
If that’s what it was (I hope so) sorry for all the above.
And today it’s working even with the Plan Views unexploded.
I seem to recall experiencing inconsistency printing from Layout Space from Make2D objects. Maybe I wasn’t savvy to the Pattern/Viewport Matching in PrintSetup. But it was confirmed by the Rhino DevTeam at the time. THere may be more going on here than my own neglect of those setting, or maybe not. I’ll keep watching out for it, because it’d be great to retain line width settings without exploding.
Thanks for these updates. We will keep on working from our side to provide a good printing results either with the model in section (in HIdden display mode) as from unexploded 2D plan and section views.
That’d be preferable. I understand that Make2D and the Views are destined for obsolence, but I hope that doesn’t happen until these sorts of things are resolved. On the Rhino side of things, resolving occlusion from meshes is going to be quite thorny, I think. It wasn’t even close to working on my most recent (and quite convoluted) Rhino objects.
Yes, any change you do in the 3D model, including attributes, won’t be visible in the 2D plan view until you update it. So I guess there is no bug at all here. Otherwise, please share the 3dm file.
Can you share that 3dm file so we can analyze how to find a solution for this case?
Since posting, I learned that the Section Attributes override the Layout and Layer weight styles.
Seems there is no bug, but a hierarchy about where the annotation style gets the information for display.
Has this hierarchy even been mapped? (ie: is there a diagram about how elements get their attributes)
Hi Kevin,
The hierarchy for assigning attributes to Plan View and Section View styles is not working well. Right now only the section pattern for section view styles are working fine. We will fix these issues in the upcoming releases.
In general, the attributes on VisualARQ objects and styles work in a similar way as Blocks and nested blocks. If you assign an attribute (“display color=red”) to an object, and insert it in a block, that object won’t change the color if you change the block’s display color. But if you set the display color “By Parent”, the object will change the color when you change it on the block. So think about VisualARQ styles as blocks, and the components (like wall layers, or door frames) as geometry inside the blocks.
Hi Kevin,
If section attributes in the object styles dialog are set By Parent,
the objects in the model will take the Section attributes assigned from the Properties panel.
@kevin, this issue has been fixed in VisualARQ 2.12.
Now, Section view styles and plan view styles have a new tab called “View overrides” from which you can define which attributes override those of the geometry displayed in plan/section views. Check this out here:
