Jump to content

Taproot

Member
  • Posts

    516
  • Joined

  • Last visited

Everything posted by Taproot

  1. You could change the view to perspective and look at it that way
  2. I've discovered a modest work around. For example: With hatches. If you select "Hatch" from the attribute pallet. Instead of selecting the hatch normally from the pull down menu (in graphic below shown as 1/4") - modify the hatch by clicking on the right hand button "Fill Hatch Settings." Normally I use that to calibrate the hatch offset, scale, etc. But, it turns out that window is MUCH snappier for selecting the hatch you want. It appears to use the older protocol - hatches are just those in the file and your "defaults" but for my use that is most often what I need. It gives me hope that the programming team may be able to refine the interface to keep the software more responsive.
  3. I've run into this issue before and found that simply quitting and restarting VW solved the problem.
  4. JHAM: We ran into a similar issue. We wanted some flexibility with the stamp portion of our titleblock, namely: 1. A "DRAFT" note for preliminary work 2. An unsigned stamp (for jurisdictions that require 'wet-stamped' drawings) 3. A digitally signed stamp. Our solution was to modify the titleblock symbol to include a "Draft" stamp on top of a white rectangle (mask) on top of the license stamps. Then as the set develops, we just modify the symbol by adjusting which objects are in front of the mask.
  5. You might try using the "Create Poly from Walls" command and see if that works. if it works, the resulting poly could be used to create the roof. If it doesn't then the problem would be isolated to the walls.
  6. Is there a way to speed up the resource manager / attributes display. For example, if I try to change a hatch on an object listed in the attribute pallet it takes 4-5 seconds to display the available hatches. The same is true of textures in the OIP. I routinely access these items, so the lag has become tedious. I'm just wondering if there are guidelines to speed this up. Should we store all of our libraries on our local drive instead of a file server? What is the best solution? Thanks.
  7. Please add hyperlink (web linking) capabilities to worksheets. That would allow for direct linking of content for all scheduled items - plumbing fixtures, doors, windows, etc. Ideally, the feature would allow for text substitution. Where a complex link could be represented by simple descriptive text.
  8. Is there a way to embed hyperlinks in worksheet cells? It would be really handy if I could just link products, mfrs, etc directly into my schedules (rather than individual links floating on the page). Thanks
  9. Alan - yes that did the trick. Thanks for the tip. I had the page resolution set to 150dpi. At 300dpi, it's acceptable. At 1,000dpi (your example) the problem goes away. Unfortunately, that means that the pdf output file size is going to be HUGE! I'd suggest this is a bug that could use some improvement.
  10. I've been experimenting with using Open GL white renderings for CD elevations i.e. no colors or textures. The door / window hinge marker in this scenario renders poorly. While the marker displays OK, since it's 3d, it's shadow is present and ... it's really pixelated. Can this be fixed? Image attached.
  11. In case you haven't checked this already... Make sure that your polygon from which the roof is created (or the polygon of a 'roof object') fill is set to "solid" not "hatch" or "none"... override the class settings if you have to. Anything other than "solid" can result in the roof objects showing up invisible.
  12. You can do this by "reshaping" the gridline object and then using the "+" option (add point) to add another handle to the grid line at the location where you want another grid line to appear. For my part, I would like to be able to double click on the gridline dimension and input the value directly (just as with standard dimensions).
  13. I read through the article that you posted and improved it further. ForEachObjectInLayer(Fnm,2,0,1); resulted in some time lag, but since you posted the resource, I found that changing it to ForEachObjectInLayer(Fnm,2,0,2); (selected objects instead of visible objects) corrected the problem and gave me exactly the result I wanted. Thanks again.
  14. Many years ago, a colleague from the Seattle user group put together a series of tools for aligning objects. For me, they are a vast improvement over the alignment command as they are fast and efficient to use. The user selects multiple objects in the drawing and then can click on a point and all objects are aligned to that point by left, right, middle, etc. Unfortunately, the tools only work on the active layer. Is there a way to revise the script to move all selected visible objects whether or not they are on the active layer? Thanks. Here's the text for the Left-Align tool: PROCEDURE Jaligny; VAR mx,my : REAL; FUNCTION Fnm(h:HANDLE):BOOLEAN; VAR x,y,x1,y1,xc,yc,dy,dx : REAL; BEGIN GETBBox(h,x,y,x1,y1); dx:=mx-x; HMove(h,dx,0); END; BEGIN GetPt(mx,my); ForEachObjectInLayer(Fnm,2,0,0); END; RUN(Jaligny);
  15. Hello Sarah, Select the window and then in the OIP, scroll down to the 'ID Tag' section and deselect "On Schedule" (see attached graphic). You can also relocate the tag (so it's not right in the middle of your window) by selecting the window and dragging the control point in the center of the tag to a new location. We don't have Windoor here in the states, so I can't help you there, but you could achieve that through the "custom" window setting. You would set up two rows of windows and assign the 300mm value to the upper window. Then you can assign muntins to that window only ... Or you could use a transom for the upper window (muntins can be assigned separately to transoms than to the main window) ... There are lots of options.
  16. I'm not sure which control you're referring to for sections, but for plan - yes the upper layers are always displayed in front. It took me a while to figure out to stack my layers up from the bottom (foundation to roof) rather than the more intuitive top to bottom. I agree, moving objects forward and back can indeed be tedious. I find separating items by layers is helpful in that regard.
  17. Alan and Zoomer: It's a fair point. The three layers per floor is a legacy from before viewports and annotations. At that time, I would place all 2D information below or above the model for correct display control. If I were building a template from scratch, I might do it differently now, but I still find the system useful. I've found the stories and "slab" tool to be cumbersome for my needs. Instead, I typically build my floors as a series of floor layers. That gives me precise control over the components (finish floor, structural system, etc without being limited by the slab constraints). Grouping them on a separate design layer gives me Delta Z control as well as the ability to more easily work on those components (gray other layers, etc...). Stories and Slabs are getting better - so over time, I may bring them into my workflow. The notes layer I still use occasionally. Dimensioning is a good example. I prefer to dimension on the design layers. It's a better workflow being able to modify them there when the building changes rather than going back and forth to viewports. Once in a while, however, I'll want to dimension a variation of the floorplan ... for instance an enlarged view of the kitchen cabinets. In that situation, it's handy to be able to turn off the general plan dimensions so that only the cabinet dimensions are displayed. If they are on a "Notes" layer, it's easy to control their display. If they were on the primary Plan layer, it's more difficult (as the dimensions auto-class). Do you find now that you can address all of your conditions with the Stories and Slab Tool?
  18. Actually, it looks like you have three roof pitches (if you count the flare at the perimeter). I would build it as three different roofs - one for each different pitch. 1. The low flare from roof slope objects 2. The steep slope from roof slope objects 3. The hipped cap from a roof object It's too complex to build out of one roof object (in my opinion). Does that help?
  19. I usually do an extrude along path for the mudsill. Reshaping a poly when things change tends to be simpler than dealing with a whole bunch of short walls. I'm glad that you found the information helpful.
  20. No scaling employed. It's just one object, so no scaling of sub-objects either. Final Quality Renderworks. I'll try adjusting the illumination values ... Yes, it is the same background. I've checked the OIP and the render settings ...works in Open GL, just not in Renderworks. That said - some of the other backgrounds work ... but several just result in the purple wash background pictured. ... a little puzzled. Upper image background replaced with a different HDRI and it works ... about 1/3 of them do.
  21. Attached is an image of identical viewports. The lower one is rendered in openGL. The upper one in Renderworks. Some of my image props disappear in Renderworks (the gal on the porch), while the trees remain. Obviously, all the classes, etc. are the same. The HDRI background is one of the stock offerings and it goes wonky in the Renderworks version as well. With numerous trial and error attempts, I've found that most of the HDRI backgrounds do the same thing in Renderworks, while a few of them display correctly. Are these things that I can correct with the settings or are they bugs? Thanks.
  22. Thanks Jim - I'm glad I've finally figured out how this process works.
  23. I'm getting erratic results with the surface hatch (rendered in openGL). Here's a screenshot of a project where we used the CMU texture that came bundled with VW. On the front side of the columns, the hatch follows the orientation of the texture. On the side walls, it appears, but rotated 90°. Is this a known bug, or a nuance of workflow that I'm unaware of? This behavior isn't isolated, the same condition exists on the chimney, front columns, etc. Which brings me to the question of error reporting (bug-submitting). I have to admit that when I looked at the method for reporting errors (here), my enthusiasm waned. Filling out a 10 item form each time; looking up the last six digits of my license; writing out everything in text (rather than posting images or posting files) seemed cumbersome and ineffective. Instead, my vote would be to just designate a forum on this board to bug-submission. Sometimes perceived bugs are simply user-error, which can be straightened out by other users. If, instead folks pile on - then it's clearly a bug. And finally, if the community knows a bug is present we can all post work-arounds and have some confidence that it's being tracked and worked on. This is already happening - I'm just suggesting that it be supported a little bit better. [EDIT] I realize that the "Known Issues" forum exists ... but I perceive that to be for bugs vetted by staff. Perhaps it could be renamed to "Suspected Bugs & Known Issues" ... or something of the like?
×
×
  • Create New...