Jump to content

panta rhei

Member
  • Posts

    359
  • Joined

  • Last visited

Posts posted by panta rhei

  1. Sorry, Peter ? I don't even try to use IFC with VW; there'd be no point whatsoever. The clients that require IFC, require a certified program to be used. Besides, the objects coming with VW are useless in Finland.

    In future, I expect to use only walls and roof faces from NNA's kit, maybe also some other items at least until I have time to program substitutes (stairs are among the ones I need to use.)

    Did some testing with your file with VW 2009 (SP 2).

    1) As is. Only the floor was imported back to VW, not a single column.

    2) Checked ?Use standard properties for this symbol? in the IFC Data dialog. VW crashed while trying to export IFC:

    3) In addition to (2), said ?Reset GUID? for each. Export & reimport worked.

  2. Christiaan, how was the traffic on the road to Damascus?

    This Mr. Ten Per Cent ? was he a contractor or a developer? In a fully implemented BIM-process there should ? at least in complex projects ? be a possibility for even bigger savings. These may or may not affect the total project cost, but should always have ramifications in life-cycle costs.

    Not that space planning and cost planning would be anything new, but BIM techniques and process enable much better means for these. A needs & requirements model can be used to test the space program and space program to test the design of the day. The cost plan is maintained throughout the project and corrective measures can be applied earlier than in the conventional process. (When 20% of fees have been spent, 80% of total costs have typically been fixed.)

    Let's assume that the design solution is such that construction costs are lower than expected. The client can either pocket the money or get a better and/or larger facility. In the opposite situation, the requirements may need to be critically reviewed and the design reworked at concept level, instead of these desperate and meaningless cost cutting exercises after receiving the tenders.

    So, risks and uncertainty are reduced at all stages of the project. This benefits everyone ? and the architect should gain more control over the project.

  3. Jeffrey,

    I would imagine that you are being paid for your work. What do you think the VW users on this board think about that?

    I've spent a considerable amount of time developing a column object that meets the needs of Finnish architects, my closest fellow VW users. Done my research, talked with users, had it tested, improved it. Nothing that would be impossible for NNA, should you want to offer actually useful tools.

    As comes to VW users outside Finland, I think I'm doing them a service by pointing out that the inadequacies of NNA's tools is not a necessity but a result of decisions made by NNA. I simply don't feel in any way obliged to donate the fruits of my labour to Nemetschek in any shape or form. I believe my peers, fellow VW developers, share this view. Does, say, Computerworks tell you how to do your job?

    Anyway, the people I've worked with are extremely disappointed and aggravated of the fact that the tools they've asked for and, yes, helped to develop, are also useless, because NNA refuses to document the creation of IFC entities with VectorScript. Just the other day I spoke with one firm: they've just decided to move to ArchiCAD. Another firm has already moved to Revit.

    I have to agree with them: those are wise, informed decisions. (Informed by action and especially non-action by NNA, including the recent lack of response on this board to one of my fellow users on the subject of IFC.)

  4. Jeffrey,

    I'm not saying that the Column object wouldn't have some nice features (at least nice in a trade show), but as a whole it is useless.

    Besides, I don't whine, I just state the facts ? and I'm more than happy to share my findings. Or rather: happy to exchange them to money.

  5. Petri, until you've seen and used the new column and pilaster tools, stop with the YOUR funny assumptions.

    OK. Let's try Column, then.

    Hmm.... Error has occurred this locked Plug-in...

    Line #297: ConvertLength := NUM2STR(xe, l);

    |

    { Error: Identifier not declared. }

    |

    { Error: Expected a string. }

    |

    { Error: Expected , }

    |

    { Error: Expected a string. }

    Well, here we are anyway.

    No, still useless. No custom shapes for concrete and timber. Not to mention that about 20 other essential features are missing.

    Pillar? OK. Nothing to see here.

    Pilaster? ?Structural type must be steel? again.

    Sorry. These are of no use whatsoever.

  6. Peter,

    Pillar and Column are two different tools. A Pillar is created from any shape, just as a floor. The Column tool is the one that makes funny Texan assumptions. (Can't remember exactly what; it's not in my workspace, because I've created a much better Column tool and use only that.)

  7. The Ceiling Grid tool is close, but Dr. Nemetschek is obviously a non-smoker and does care about cigars.

    1. Why does it have to be ?Ceiling Grid?? Why not just Ceiling? (Are there ceilings in Texas? Probably not.)

    2. Why can't one turn off the grid?

    3. Why isn't there a separate 3D-class?

  8. Could someone please pass the salt ? I think I need a pinch with an IFC-related statement by a NNA staff member. There was supposed to be excellent IFC already from VW 12.5! Here and now, I think it was. Including IFC with VS.

    Anyway, I agree with the workflow priority. It seems that in most projects at least in Finland IFC is primarily used in coordination and design data are still moved around as DWG.

    (Good news about GUIDs!)

  9. I think you're wasting your time trying to get VW to do valid IFC. The same may apply to some other programs, too, but import tests (from VW) run by a friend of a colleague, with several IFC-certified programs (VW is NOT certified) were not exactly convincing.

    Apart from that: IFC and symbols are not really conceptually compatible. (Not sure about the actual implementations.) An IFC entity should have a persistent GUID (Global Unique ID): the same GUID in every export. An IFC entity in a symbol? Maybe NNA's IFC export can assign GUIDs, maybe nowadays even persistent ones ? but the last time I tested, the GUIDs changed every time. So much of usefulness...

    Maybe you should try NNA's Column object?

    Whoops! The Wizard of Tex does not know that concrete columns can have a shape!

  10. Ahh, thanks again! I must've seen it because the assuring notes seem familiar:

    On the Mac, this returns gibberish if the file has not been saved yet. To trap for this, use GetFName to see if the filename starts with 'Untitled'.

    On the Mac, it also returns gibberish if the file name is greater than 28 characters in length

    We lovess gibberissshh...

    The suggested trapping is nonsense. A file can be saved as 'Untitled'.

  11. The visibility of this call is FALSE in the normal VS documentation! Thanks to DWorks, I started to look for it and found it!

    I have some PIOs where the control points are needed only in some circumstances and then others that would benefit from more of them, but the user interface has been a problem.

    SetCntrlPtVis

    Description

    Sets the visibility of the specified control point.

    PROCEDURE SetCntrlPtVis(

    inCustomObj :HANDLE;

    inContrlPtIndex :INTEGER;

    inIsVisible :BOOLEAN);

    Parameters

    inCustomObj HANDLE

    inContrlPtIndex INTEGER

    inIsVisible BOOLEAN

    Eg. SetCntrlPtVis(obHan, 1, FALSE);

  12. OK, thanks! Not exactly what I was hoping, but it'll do for the time being.

    It seems to be impossible to get entirely rid of the stupid line: if the scale is changed, it comes back.

    In the afternoon I actually created a prototype of a PIO that reads the viewport name when in annotation (and gets updated) and also outside one when placed, but of course in the latter case linking is not possible. The two modes are probably too confusing; have to think about this. Some technical problems, too: triggering the update of the PIO.

  13. ???You can, if you indent your source code with tabs. First, replace all tabs with three option-space (NBS = non-breaking space) characters,

    Nice! Have to try...

    The use of dynamic arrays can get around the static array limit, but you have to count everything first then declare your array size, and even then you are limited to 32K elements, which should be enough for most everything, but it's still not bullet proof.

    Duly noted, but I think we can quite safely assume that few scripts need to handle more than 32K elements.

    Counting is not that bad. In my example this would have been the better approach:

    VAR

    i, n, objType : INTEGER;

    x, y, z, a : REAL;

    xi, yi, zi, ai: DYNARRAY[] OF REAL;

    theSymbol, lName : STRING;

    obHd, sdHd : HANDLE;

    ????

    BEGIN

    ????????????theSymbol := GETSDNAME(ACTSYMDEF);

    ????????????IF (theSymbol > '') THEN BEGIN

    ???????????? lName := GETLNAME(ACTLAYER);

    ???????????? n := COUNT(SEL & (L=lName));

    ???????????? ALLOCATE xi[1..n];

    ??????????? ?ALLOCATE yi[1..n];

    ???????????? ALLOCATE zi[1..n];

    ??????????? ?ALLOCATE ai[1..n];

    ???????????? obHd := FSACTLAYER;

    etc.

  14. Well, here's another take on the subject. I've totally forgotten the circumstances, but obviously the 3D & rotation aspects are there for a reason.

    PROCEDURE Sel2Syms; { ? Petri Sakkinen 1998-2009 }

    { This macro replaces selected objects on the active layer with instances of the active symbol }

    VAR

    i, n, objType : INTEGER;

    x, y, z, a : REAL;

    xi, yi, zi, ai: ARRAY[1..1000] OF REAL;

    theSymbol : STRING;

    obHd, sdHd : HANDLE;

    BEGIN

    theSymbol := GETSDNAME(ACTSYMDEF);

    IF (theSymbol > '') THEN BEGIN

    obHd := FSACTLAYER;

    WHILE obHd <> NIL DO BEGIN

    i := i+1;

    x := 0; y := 0; a := 0; z := 0;

    objType := GETTYPE(obHd);

    CASE objType OF

    9 : GETLOCUS3D(obHd, x, y, z); { found a 3D locus }

    15 : BEGIN { found a symbol }

    GETSYMLOC3D(obHd, x, y, z);

    a := GETSYMROT(obHd);

    END;

    17 : GETLOCPT(obHd, x, y); { found a 2D locus }

    OTHERWISE HCENTER(obHd, x, y); { found something else}

    END; { case }

    xi := x; yi := y; zi := z; ai := a;

    obHd := NEXTSOBJ(obHd);

    END;

    IF YNDIALOG('Delete selected objects?') THEN DELETEOBJS;

    FOR n := 1 TO i DO BEGIN

    SYMBOL(theSymbol, xi[n], yi[n], ai[n]);

    IF (zi[n] <> 0) THEN MOVE3DOBJ(LNEWOBJ, 0, 0, zi[n]);

    END;

    END

    ELSE ALRTDIALOG('You must have an active symbol');

    END;

    RUN(Sel2Syms);

×
×
  • Create New...