Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Taproot

  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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).
  9. 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.
  10. 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);
  11. 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.
  12. 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.
  13. 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?
  14. 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?
  15. 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.
  16. 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.
  17. 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.
  18. Thanks Jim - I'm glad I've finally figured out how this process works.
  19. 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?
  20. It's been a while since I set up our titleblock, but I recall that using multiple fonts was problematic. I ended up converting fonts to polylines to keep their appearance correct. So - multiple font support. Page margins and titleblocks are an on-going challenge for us. We typically work on 24x36 size pages, but print check sets on 11x17 at 50%. Our page margins are set up to accommodate the difference in paper size. Whether we are printing at 100% or 50%, we would prefer to have the pdf scale from the center of the right hand side. Currently, it scales from the center / middle of the drawing. Our work around is to insert a loci in the titleblock symbol for check sets and then delete it once we get to construction drawings (so that the titleblock slides right to the edge of the page). It's not an elegant solution. See Graphic. I think the best solution would be to add the ability to scale pages in the "Publish>Options" window and then be able to control from which point the sheets are scaled i.e. eight choices including page corners and centers of each side. So, while this isn't a direct change to the titleblock settings, the issue seems best brought up here.
  21. There is no way that I know of. If you're hatch idea works - let us know.
  22. I'm pretty sure this was a bug fixed in service pack 2 (2017). I can do it now (Mac - El Capitan).
  • Create New...