Jump to content

Bret

Member
  • Posts

    106
  • Joined

  • Last visited

Posts posted by Bret

  1. Thanks for confirming, Jim.

    I have never understood the logic behind leaving that particular format out of Fundamentals - .pdf is a universal standard for information interchange, much more used and much more basic than Cinema 4D, Rhino, Parasolid, and many of the other proprietary ones which are included with Fundamentals. For an engineering office of our size, though, the fairly high cost of upgrading everyone to Design Series licenses outweighs the benefit since there are so few features we would actually benefit from.

    Anyway, I'll remake my annual request: please include .pdf support for the Fundamentals license...we would appreciate it greatly.

  2. Jim,

    Our engineering office currently uses VW 2014 Fundamentals. The new feature matrix lists "Robust PDF Integration" as included for Fundamentals users, and the VW 2015 Help file lists several .pdf-related options as being available for Fundamentals users.

    The ability to import .pdfs is one of the few Design Series features we'd actually use (along with Publish), and I got my hopes up there for a minute. However, it doesn't look like .pdf importation is actually provided, despite what the new feature matrix seemed to imply...is that correct?

    Thanks.

  3. 1) a project is highly repeatable and/or highly complex and/or quite large

    I must say that our smaller/easier projects are getting more out of bim and are faster then we did them without bim. So I would sugest it to everyone, especially with smaller homes. But of course, your library, standard files and class system have to be made for it to be able to get it done. Because we have set all into place, I have done 4 small homes in 3 days in design phase and was able to show the level plans, elevations, simplified section, 3D, Interior renders and terrain. Ok, it's all basic at design phase, but you get a lot of a well build bim library!

    Bigger, more complex buildings require more 'hand-made' symbols because most pio's just can handle standard situations, therefore, the bim we have in VW out of the box is better for small standard buildings.

    I'll upload the file: Here

    Thanks for sharing that...

    I suspect that the simpler the project, the smaller the time difference between 2D and BIM probably is, but also, the lesser the overall benefit of BIM. Still, if our architects set up the plans like yours, as opposed to us having to do it ourselves, I'd be more willing to dive in and really check it out.

    That ties into my point #2 - Right now, it's pretty efficient for us to communicate most structural designs with 2D drafting using architectural bases and our library of standard 2D details (with additions and customizations as necessary, of course). Unless we're given a BIM base model to work from, it's not going to be a time saver, and we're not being given BIM models.

    From a wider perspective, the ultimate question is whether or not the benefits of working in BIM offset the extra design time and provide net cost savings and/or better buildings. My answer thus far has been, "For our engineering firm, taking into account the projects we do, the people we work with, and the state of BIM: not yet."

    As a side note, unless big steps are made, I'm not expecting that the eventual switch to BIM in our circles will come from VectorWorks users choosing to stay within the VW system. Everyone we've worked with who has moved or thought about moving to BIM (including one or two architects whose firms started in and then backtracked) were talking about that other program. I suspect the problem is not merely technical but educational as well.

    Anyway, most of this is really a topic for discussion in another thread...sorry for the detour.

  4. That Fundamentals users would be brought into conformance with the Design series with regard to a handful of basic file organization standards and capabilities: DLVP, PDF support, detail viewports, rotatable axis...batch printing would be nice too.

    (Yeah, I'm obviously coming at this from a lower-tech angle than most of you, but still...)

    Why dont you just hustle clients directly with Architectural/Structural/Energy BIM and with the extra cash upgrade...IMO (we) Real Engineers are in the driving seat on project, presentations, data and control.....step up man theres a S*** Load of money to be made.

    We've looked into BIM on and off, and for most of the types of projects our structural firm does (high-end custom homes, low-rise commercial, educational, solar, etc.), I'm not convinced that the utility is there. If it were, we'd make the pitch, but I just don't think it's cost-effective yet unless 1) a project is highly repeatable and/or highly complex and/or quite large AND 2) everyone on the team is on board.

    The architects we're working with are (mostly) working in 3D but very few are using BIM at all. I haven't heard any push from the mechanical or energy guys either. Clients don't want to pay for it, not for the extra time it takes in design and much less for subsidizing our office-wide upgrade.

    (I was at a meeting a couple of years back where another structural engineer spoke on BIM, and he said that after thousands of dollars in upgrades and training and over a year of 100% switchover at their office, it only took them 30% longer to produce the same plans...with real but indeterminate amounts of cost savings. Not a strong sales pitch, especially when most of our projects are much smaller than theirs.)

    BIM may be the future, but we're not "hustling" anyone unless/until we think it'll really benefit a project.

  5. I know it's probably to late to be useful, but I thought I'd air my biggest immediate requests one more time:

    1) Direct2D/DirectWrite/etc. support for Windows (since GDI+ font handling is basically broken)

    2) Full 64-bit support

    3) That Fundamentals users would be brought into conformance with the Design series with regard to a handful of basic file organization standards and capabilities: DLVP, PDF support, detail viewports, rotatable axis...batch printing would be nice too.

    (Yeah, I'm obviously coming at this from a lower-tech angle than most of you, but still...)

  6. My preference is also to have it come out on 'By Class' so that it could be globally edited later should I want to do so. In my case, it should be created with the 'By Class' default fill of 'None' regardless of the 'Create text without fill' setting.

    Manually setting it to either filled or unfilled doesn't do what I'm aiming for. There is a conflict between FPatByClass and 'Create text without fill,' which I've now reported; the sequence of operations I gave them to replicate the problem is listed below, if you're interested...

    1) Create a new blank document

    2) Create the XXXXX class referred to below and set its default fill pattern to 'None'

    3) Check the VectorWorks 'Create text without fill' option

    4) Create a new VectorScript as shown below

    5) Run the VectorScript -> the text is incorrectly created with a fill

    6) Uncheck the VectorWorks 'Create text without fill' option

    7) Run the VectorScript again -> the text is correctly created with fill set to 'By Class' (None)

    --------------------

    BEGIN

    PushAttrs;

    NameClass('XXXXX');

    FPatByClass;

    TextOrigin(0,0);

    BeginText;

    'This text should not be solid'

    EndText;

    END;

  7. Miguel,

    Thanks for reminding me of those. We had actually used those in some old scripts, but I had forgotten about them.

    After switching to use those, I'm having an issue with text coming out set to solid fill, even when the class setting is for 'None' (not to mention that 'Use at Creation' is checked for the class and that 'Create text without fill' is checked in my VectorWorks Preferences). For some reason, this happens whether or not I include FPatByClass in the code.

    However, I just discovered that if I turn off 'Create text without fill,' it works correctly and gives me unfilled text set to 'By Class.' I think it's time to file a bug.

  8. On the PC, VectorWorks has issues with fonts when GDI+ imaging is used, as I posted here (and then contacted tech support about):

    http://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Main=33174&Number=163531

    In my e-mail correspondence with tech support, it seems to come down to the fact that font handling is broken in GDI+; it only correctly embeds/outputs fonts which are 100% valid for GDI+, and these are very rare, if they exist (Arial and Calibri don't even work, according to the validation tool).

    GDI+ is a deprecated technology, and VectorWorks basically needs to implement Direct2D, DirectDraw, etc. on Windows for any of this to be fixed properly. At this point, we just make sure that GDI+ is turned off when we print to PDF...and complain from time to time.

  9. In a Command we've written to call out hardware on a plan, we currently use PenSize, PenPat, and FillPat to set visual defaults for a line and some text, but I'd like to force these to be by "By Class" when created. Is there a way to do this?

    I've taken a look through the forum and the online VectorScript reference, but I haven't run across anything helpful yet. (I see how you can use FFPatByClass etc. to query whether this is the case, but not how to force the setting.)

    UPDATE:

    Okay, I've figured out one way to do it by using SetLSByClass(LNewObj) etc. after every created object, but it would be nice to be able to set all of those things globally at the beginning of the code.

    (It seems that leaving the "Use at Creation" box for the class checked would solve much of this, but it doesn't seem to work for the fill pattern setting if you have it set to "None.")

  10. Ian,

    Thanks for the reply. While possibly related, I think this is a separate issue.

    I just turned GDI+ back on and checked text with 50% opacity vs. text with a transparent background vs. text with a filled background, and it makes no difference to the print quality. The opacity is reflected correctly in the .pdf, but the font output is still broken.

    All works (and prints) correctly when I simply untick the GDI+ box...something else must be going on.

    P.S. Attached are two .pdf files showing my typical text print output with GDI+ on and off...no other difference.

  11. Our engineering office has recently updated to VW 2012, and in getting everyone up and running, we've started looking into features we hadn't used before, such as transparency. While doing so, we're discovering problems with GDI imaging, and I was wondering if others out there have had similar issues.

    The first noticed was that the printing of text appears to be broken when GDI imaging is turned on (which I previously posted about here and later submitted as a bug report).

    Now that I have GDI imaging turned off, beyond the loss of transparency and anti-aliasing, I'm starting to notice graphical inconsistencies - nothing mission-critical, but annoyances nonetheless. For example, when hovering over an object, the pre-selection highlight is often offset by one pixel toward the top of the screen. When this is the case, if I select that object, it will appear to shift upwards by that one pixel, although the object doesn't actually move.

    Any other users out there running into issues like this?

    P.S. In searching the forums, I've seen some isolated mentions of similar problems, but nothing like a real fix or resolution:

    fonts

    worksheet - font mapping problem?

    printing/visibility nightmare

  12. On Windows machines in our office, when I print to pdf (using pdfFactory), I have to turn off GDI+ imaging to make the fonts embed correctly. My print output results are as follows:

    GDI+ imaging = ON:

    - At an output setting of 300 dpi or lower, letters rasterize and become pixelated, and they cannot be selected with a text tool in the pdf.

    - At an output setting of 360 dpi or greater, letters appear to be rendered as (chunky) polylines which also cannot be selected with a text tool.

    GDI+ imaging = OFF:

    - Text embeds correctly, regardless of resolution.

    Any idea why this on-screen imaging setting affects my print output? Is this a bug?

    (I believe this problem has existed at least since v2008. We've generally run VW without GDI+ imaging turned on in previous versions, since there was less functional benefit lost without it, but we'd like to take advantage of VW2012 features which require it.)

    UPDATE: After reading the kbase article here, I thought I'd add that I see this with both older fonts like Arial and newer ones like Calibri.

  13. Kizza,

    What do you mean?

    Vectorworks has had native PDF support for both Mac and PC for a LONG time.

    Too bad they (still) strip PDF functionality out of Fundamentals, as well as batch printing, DLVP, and a handful of other relatively basic features I'd expect from a software package that is still described as "professional" in the brochure.

    (I suppose this is really another conversation...although it's one I've never gotten much response on when I've tried to start it in the past.)

  14. From your blog, it looks like you upgraded to Vw2011 from Vw2008. Not a good thing, because your legacy files were made before the switch to parasolids.

    Respectfully, I'm pretty sure that the VW2008-2011 conversion could be much more reliable than it is. The problem is that it's a complicated problem, and apparently NNA has decided not to invest the time needed to ensure reliable backwards compatibility.

    Our engineering office has thousands of job files which are compatible with VW2008 (and many older ones with VW 12 as well), and we're dreading the upgrade. Not having access to those job files is not an option, and having to keep VW2008 installed is a pretty weak "solution."

    (We're also unsure how our mostly-older PC machines are going to handle it, even with 2D work, but that's another topic.)

    BIM = efficiency

    Depending on the type of job, it is a possibility. However, I'm still not convinced that the extra design time needed (vs. basic 2D or even 3D drafting) pays off for most small-to-medium scale projects, assuming the competence of all involved in the first place.

  15. Yes I am finding out more now as 3d section and open GL, in the toolsets at least 50% have an annoying red cross through them. It seems that over the years the developers have split of the various elements of the original Vectorworks to make as much profit as possible from us.

    'Milking it' comes to mind. As you say it's not cheap but their tactics are particularly as you have to purchase each update release to climb the ladder to get the latest version. It's ok for large practices but for the small guy it's not economic.

    I share this same frustration that these abilities still haven't been added to Fundamentals. These are basic production and interoperability functions, and there's nothing "industry-specific" about them. Fundamentals is billed in the brochure as a professional product, so these are the types of features that I'd expect not to be excluded.

    Our structural engineering firm doesn't need 95% of what comes with Architect, and it's just not reasonable for us to upgrade every seat in the office for a small handful of abilities like these. We've been using VectorWorks Fundamentals for about a decade now, and we definitely feel like NMA is particularly omitting a few key elements as enticements to get people to upgrade.

    Maybe in v2012? If so, we might finally brave the v2008 translation issues that seems to be eating some computers.

    (Sorry for the rant, but I feel compelled to comment on this from time to time, and it's been a while.)

  16. Our structural firm uses VectorWorks (Fundamentals), although we have one client who is going to require us to get a copy of REVIT Structure. We're not really excited about it, but I have to say that I'm curious to see how REVIT model collaboration will work out, and how it will interact with the analysis software we use.

    I'd love to see VectorWorks develop real interaction with RISA/ADAPT/etc. (oh, how I dream of creating layouts in a real drafting/modeling program!), but I don't expect it to happen soon for a couple of main reasons.

    First, most structural engineers are using AutoDesk products, so the analysis software companies focus their limited resources on interacting with those products. Second, we engineers are a small minority of VW users, so I don't honestly expect NNA to dedicate too much effort into promoting this either.

    Unfortunately, these problems feed off of each other, and I think the only way to get VW (and VW-as-BIM) accepted in a more widespread fashion is for Nemetschek to make a concentrated proactive effort into making these connections.

  17. I've mentioned this before here on the boards, but I think Leonard's example above shows where BIM is most useful--Frank Gehry-type projects. BIM definitely has the potential for savings if you're doing projects which are: 1) quite large; 2) highly repetitious; and/or 3) highly irregular in form.

    However, my view is that if you're working on humbler projects (e.g. single-family residences, small tracts, smaller commercial projects, etc.), then the extra work it takes to implement BIM is neither time-efficient nor cost-effective for the client. I don't know if it ever will be, but I guess that remains to be seen.

    As for our mid-sized structural firm, we'll be holding off on BIM until we start bidding on the type of projects which need it.

  18. Let me just stick my head in here briefly to lobby for design layer viewports to be built into the Fundamentals package as well.

    I can see why things like object libraries and advanced rendering features would be held aside for Architect users. However, I think it's odd (and disappointing) to see NNA deprecate basic tools and yet leave Fundamentals users stuck with the old ones and limited interoperability.

    Our structural office won't use 95% of the tools that come with Architect, so it's probably never going to be worth the cost of upgrading everybody. Still, there are a few tools we'd like which seem, well, fundamental for general professional use, and we've often wondered why they're not in the Fundamentals package: the aforementioned design layer viewports, batch plotting, etc.

    Now back to your regularly scheduled discussion...thanks.

  19. With all due respect to the AIA, Nemetschek, Jeffrey, etc., I have yet to be persuaded about the utility of BIM for most projects.

    I can see that it may be useful for projects which are very large, very complex, and/or very repetitive, but the vast majority of projects built do not fit this profile. For the typical projects our structural firm works on (high-end residential, light commercial, schools, etc.), there's no sufficient justification for the significant increase in both fee and timeline that BIM modeling would require.

    I think Jeffrey says it well when he calls a BIM model, "an integrated, virtual construction..." If there is complexity or scalability enough in a project to warrant assembling a building twice, once digitally and once physically, then it's a great tool. In my experience, though, this does not describe most projects.

    We will probably get to that point someday, but I suspect it's farther off than most think. As far as I can tell, too many of the tools which would get us there (3D collision detection, simple yet robust tools for information tagging, etc.) just aren't developed enough. And I think you have to be pretty removed from the construction process to think that paper will be succeeded as the default medium for plan check submittals, on-site use, etc. any time in the near future.

    Two cents from an engineering perspective...

×
×
  • Create New...