- Checking/Unchecking “Show BOundary” in properties for a plan view doesn’t respond as the tutorial implies (by RMB click in model space somewhere). It doesn’t respond unless vaUPdate is run on the Plan View, which updates the PLan View wrt any model changes despite “Auto Update” being unchecked. Shouldn’t these two views be separate, as the tutorial implies.
- Editing a “from curves” boundary doesn’t update properly. IN the case of a boundary reduced in size; the original boundary is retained, with segments of the new boundary showing as linework within the original boundary whether “Show Boundary” is checked or not.
- Yes, we are aware of this limitation. You need to manually update Plan views to see the changes done on the “Show boundary” checkbox. The Auto Update option of plan views only affects when changes are done in the Level Manager, on the Level that the Plan view displays.
- You are right. There’s a bug when editing the control points of plan views created from curves that are scaled. We will review that and fix it.
1a) I understand this means that the boundary display can’t be changed without updating the plan view. A very important thing to remember when creating a set of documents. Please let me know if I don’t have that correct. (Not sure if it’s the best arragnements, btw)
1b) So Auto Update (or not) only applies to responsiveness to elevation, cutplane and offset settings. Please let me know if I don’t have that correct either.
2) Clarified, thanks.
3) (New) I notice that if a PLan View is moved, it’s automatically updated. (As with Section Views.)
1a. That’s correct. We could change the way this works, but we considered that since the boundary may trim parts of the plan view drawing, not updating the plan view would generate confusing results.
1b. Yes, that’s correct. In addition, it also updates when changing the plan view’s title.
3. That should not happen, and I haven’t been able to reproduce it. Can you send a model where that happens to email@example.com?
By the way, since VisualARQ 2.0 version, when showing the model using the Hidden display mode, you can print it directly to pdf as vector output. That means that you can show the model in section, elevation, plan view, arranged in Layout Details and print it in good quality vector lines. Have you tried that? You can watch it in this video: https://youtu.be/1qdNB5v_fwE
This will avoid you having to insert tons of additional 2D geometry, caring to have the 2D drawings up to date, and therefore you will improve file size and speed performance.
Appreciating your prompt replies (despite my being intermittent here in recent days). I’ve emailed such a file.
By the way, since VisualARQ 2.0 version, when showing the model using the Hidden display mode, you can print it directly to pdf as vector output. <
I’ve noticed that and wondering in which (if any) cases the Plan View or Section View is recommended instead. (I’ve discovered in working with Rhino without VisualArq that the mesh display interferes with hidden line display in the case of some heavily articulated objects, so I’m using Make2D in most cases for that reason. Otherwise using model views would be most efficient.)
I always recommend using the option to print the 3D model in section-elevation or plan view using Hidden display mode for printing purposes rather than generating 2D plan and section views with the vaSectionView and vaPlanView commands, except when you need to export these drawings to dwg.
When using the Make2D for mesh objects, do you get a clean 2D drawing immediately? or do you need to manually remove the undesired mesh lines?
Can you send me an example of how you wish those objects were shown in Hidden display?
Ah - importing to dwg. That’s the particular purpose for the “Views.” Appreciated.
As to the mesh display interference issues, they preceded my experience with VisualArq. They were a problem creating construction drawings of heavily articulated curving Rhino polysurfaces. Even in Make2D, I had to selectively erase certain lines and hide certain layers, but in any model view with hidden line removal, too many lines were occluded by the facets of their own mesh to make the images workable. I am understanding that this was a very different situation from the relatively far less articulated architectonic volumes for which one would use VisualArq. So it’s good news to be liberated from the Make2d-type process.
As a spate of my recent posts indicate; Orthographic Detail views in Layout Space have quite a few issues. I’m almost ready to try Plan Views again. In any event, DImension placement unreliability in layout space means it’s best to dimension in Model Space.
I did a tiny bit of AutoCAD then over to Revit as my main tool: what are the advantages of dimensioning in layout space (if it worked the way you wanted) ?
(Sorry for going off topic; just curious to undrrstand it: there’s no comparible workflow that I’m familiar with)
Printing from hidden view would be great if it really worked. Right now it’s about 80% that Rhino will crash (rhino pdf in hidden view with plan display) or some things will be missing in the file printed that way (other pdf printers). Printing plan views calculated in model in wireframe mode is the only stable solution right now.
Thought I’d try it as an alternative to the layer management issues of a lot of dimensions within a model.
Thanks for the tip, Tomek. I find hidden more stable than that, but I discovered something (I forget what) that Hidden doesn’t do as well as Wireframe does.
That’s what I’ve discovered.
I have given up on Top Ortho Model Views for Plans for now. There are posts from me elsewhere about each of the below, I hope they aren’t all bugs and that a few may be problems with my settings, but together they add up to too many disappointing issues:
A. Disappearing sloped-slab ramps
B. Dimensions connecting lines and objects are not resilient to editing in either Model or Layout Space.
C. Level Display settings aren’t consistent in their results.
D. Doorways show thresholds erratically and without apparent cause.
E. Door Swings disappear without apparent cause.
F. Wall Cut Plane edges won’t display consistently if their colour is different from the wall’s fill colour, print with irregular drop-outs and rounded rather than 90 degree corners, and depict window sills as thickened cutplane edges. One wall provided a thick cutplane edge only at window sills and left the actual cutplane edges at default (and that wall was only selectable at the window jambs.)
G. Lines of apparently identical Linetype scale settings don’t match in print as when set/scaled/displayed.
H. Lines that are coplanar with slabs (which by default all lines will be) don’t print. But “PrintDisplay” shows them so the issue only shows up when printing.
I. Every drafting-oriented View Mode other than Wireframe provides a corrupted view of some sort through a Detail Window in Layout Space.
I hope Plan Views work better despite the issues that began this post.
Can you make it crash again? Please send us the .dmp file so we can figure out what happening and fix it!
If there are some missing lines, try to print the model with a better output quality. If problem persists, please send us the case so we can analyse it and improve the vector output results.
@djhg I’ve seen and commented all your posts, and here it is a brief summary of each one:
A. With a better output quality (DPI) this problem goes away.
B. This is a Rhino 6 bug when dimensioning blocks and 2D geometry. Someone that does not have VisualARQ will get the same issues. We will see if we can improve that when VisualARQ objects are involved.
C. I missed this one. Can you provide more information? (in this or in a new thread)
D. I still haven’t been able to reproduce this issue.
E. This seems to happen when resizing Details. We are working to fix this.
F. We are looking at these issues.
G: Can you provide more information of this one? (in this or in a new thread)
H. I could only reproduce this error when lines were below the top surface of a slab (hidden by the slab, basically), and they were “Brought to front” with the Rhino command. We are taking a look at this. But I could not reproduce this error when lines are coplanar with slab top surface. This has been reported here, but I need a file to test this with.
I: Can you provide more information about this one?
These issues have their own threads at this point, except the below:
G) This is happening with the grid lines in the projects I’ve uploaded and should be evident if the line types and scales are customized. Might be a Rhino thing.
I) Most of these are mentioned in other posts. There’s a gif or png of Hidden Mode in the post about Plan View issues which led to a long flirtation with Model Views. Technical Mode doesn’t show fills and tends to show joints.