mike m oz

VW needs to take this next step so that it can compete effectively with its opposition. Please say it is coming!

Definately needs to be added in the next release

I would like to see information returned in the OIP about whether a door or window inserted in a wall has been flipped (ie mirrored). The reason for this is that the the appearance of glass differs when rendered in Renderwork depending on whether the symbol has been inserted in normal orientation or mirrored. Currently there is no way of knowing until after you render the image. You can correct 'the flip' for symetrical doors or windows quite easily but this problem means that left and right hand versions of non symetrical symbols need to be created for a correct rendering rather than just mirroring them. The problem is not restricted to just surfaces with transparency - I have noticed variations with other surfaces as well. Julian Carr of OzCAD has advised me that it is to do with the direction of 'surface normal' and that nothing can be done about it. I accept this as being correct. However the issue needs to be explained in the renderWorks manual and in my opinin the orientation (ie. flip or mirror) of the PIO or symbol needs to be returned in the Object info pallette so that the obvious inadvertant mirrors can be picked up easily and corrected. PS I did try to paste an image showing this problem into here without success. I will email it to the NNA tech people and hopefully they will be kind enough to insert it in for me. Image added 14 Jan 05 - this quite clearly shows how different the appearance is when the same symbol is mirrored. [ 01-15-2005, 10:08 AM: Message edited by: mike m oz ]

VectorWorks doors and windows frustrate the b... out of me. Place a door or window on the page so you can edit it to what you want for placement in a wall, or to turn it into a symbol. To see it from the front you have to go to a back view, and... To see it from the back you have to go to a front view. Ditto for left and right and the various isometric views - all opposite hand. Whilst I assume the reason for this relates to the mathematical degree protocol - the in use logic is a nonsense. THE FRONT SHOULD BE WHAT YOU SEE IN A FRONT VIEW! And so on? A simple change to the PIO?s would solve this annoying logical conundrum and make the use much more intuitive (particularly so for new and novice users) And yes I do realise that you can turn the PIO?s around after placing them so that you do see them from the front ? the point I am trying to make is that the program should be geared to the user?s logic and not the programmer's logic. The endeavour should always be to make the program as easy and intuitive to use as possible. The current door and window PIO logic is the antithesis of this.

Both stair tools need a make over so that they can do what the users want. For example the lack of being able top do 'square' winders paticulartly frustrates me.

A plug in that would create odd shaped windows such as circles, half circles, hexagons, triangles, etc would be a boon. Particularly if it would also create an empty opening.

I also support the need for variable vertical elbows. Ductwork quite often has to offset up and down to avoid obstacles or go into areas with lesser head heights. This is invariably done with angles other than 90? to lessen the resistance effect of the elbow on the airflow. Please add this improvement.

Agreed - subdirectories would be a good way to go I also think hatches need to be organised into different drawings so that individual hatches can be found more easily (I have started doing this for myself - if and when i get it finished I will email to NNA)

Can I please add my wish for this also. It is one of the few advantages AutoCad has on us - having this feature in VectorWorks would make life much easier.

Better still would be the capability to see the layer scale either in the mode bar at the top of the drawing area or in the border at the bottom of the drawing alongside fit to objects etc. Even better still would be the capability to change the active layers scale from this location. More extensive scale changing (ie. multiple layers) could remain as it is now.

Robert For 'live' sections (and I am assuming you are working on these to achieve parity with the opposition - ie ArchiCad and Revit) ceilings have to to be real 3D objects. There are three componrents to the BIM: - accurate 3D representation for selling and communicating - 2D drawings for building from - accurate data returns for estimating the cost. If you are really committed to BIM then you should be moving towards an integrated environment that satisfies each of these needs. Facility management should also be an objective - we need to be taking a broader view that does not isolate just the design / build process as what we are interested in. The proportion of new buildings built each year is a small fraction of the total building stock which exists. Intelligent building management is an opportunity for Vectorworks that I hope you are exploring!

Robert For 'live' sections (and I am assuming you are working on these to achieve parity eith ArchiCad and Revit) ceilings have to to be real 3D objects. There are three componrents to the BIM: - accurate 3D representation for selling and communicating - 2D drawings for building from - accurate data returns for estimating the cost. If you are really committed to BIM then you should be moving towards an integrated environmr=ent that satisfies each of these needs.

ADJUSTING HEIGHTS AND SLAB THICKNESSES SHOULD BE POSSIBLE IN THE MODEL SETUP DIALOGUE BOX Model Setup works fine if you know exactly what your floor to floor heights and slab thicknesses are at the beginning of a project. If however you want to adjust these afterwards it will not accept any changes - these have to be done manually in the Layers dialogue box. And yet if you add or remove a floor it will adjust the heights. The logic is inconsistant and it is not user friendly! Can it please be changed so that it will accept height and slab thickness changes and adjust everything accordingly. MODEL SETUP SHOULD DO THE MATHS AUTOMATICALLY This second issue relates to the logic of how the heights are entered. It would be better if for each storey there were four heights to be entered: A floor to floor height B slab below thickness C ceiling height D height from underside of ceiling to floor over This would then allow the program to calculate the heights of respective elements automatically. A and D should also be linked so that adjusting one will adjust the other. Allied to this is the need for a ceiling object - A necessity if 'live' sections when they are introduced are to be useful. javascript:void(0)

I THIRD THIS It is a pain in the butt having to reposition plug in doors and windows relative to the centre of them. I understand the logic of why this is so but surely the PIO could return the object width to the position dialogue so that its position could be set to an edge. Better still would be a graphic dialog box which showed the object width and the dimensions in each direction to the ends of the walls (with the option of selecting inside - centre - outside) with the capability to change all of the dimensions as required with the objects location and/or width adjusting accordingly.

We Architect Australia users have a camera object courtesy of Julian Carr's cleverness.

Ctrl J works on lines so why not on other joining situations? Surely consistancy should be the objective. Makes sense to me.

The importance of this issue appears to have been lost in the jousting of the replies. Petri's original request is about a real issue which does need addressing. In the design development process walls do have a habit of changing characteristics and therefore width. being able to change the width relevent to a particular reference point like the outside is a necessity. Fortunately for us Australian users Julian Carr has managed to overcome this issue successfully in the Australian version of Architect - so surely it is not an insurmountable problem. Similarly he has given us the capabilitry to do corner and bay windows which the basic architect version cannot handle. The bigger picture however is the need for some of these type of needs to be addressed in the core program so that all users have this flexibility. The program needs to become more intelligent and respect the fact that change is the norm these days and not the exception. Improving the capability and flexibility of some of the core capabilities like walls, floors, stairs, dimensioning and the like should be an imperative for 11.5.

I also experience in VW11 the line weights randomly changing to being in mils rather than the mm I prefer. In previous versions I noticed that this commonly happened whenever the program crashes or a force quit is used due to the program becoming stalled. Would suspect it is still the same issue.

Julian Carr at OzCad here in Australia produced a tool as part of the OzCad pack that allowed rotated rectangles to be resized as you wanted through the OIP Would be worth contacting OzCad ( www, ozcad.com.au ) to see if it still available and functions in VW11

I have similar results with the same bizzare "Edit Plant Catalog' message withVW11 on OS X on a mac

More 'intelligent' floors would be nice. ie. - separate textures for top bottom and edges - ability to add holes like in the roof objects - ability to reshape as per the roof object

Having the bottom Z height of extrusions (relative to the normal plane) in the object info pallette would allow quick and easy elevation of custom items. Would also be nice if it worked on other 3D objects and groups of 3D objects as well.

Built in curved roof capability would also be a desireable feature. Of course having the same desired roof - wall interaction 'intelligent' relationship would be nice. I suppose that is my major beef about the program these days - the slowness in providing the 'intelligence' that can be seen in many other architectural CAD modelling programs.

Winder option with square corners is essential on standard stairs very common requirement - it can be done manually but it is a real dog having to do it and of course if you have to make changes.... Seems to me like an issue for one of the programmers to get their teeth into.

Petri I have tried the method you so kindly provided and yes it does work. I still maintain however that it shouldn't be this hard. If you have used several of the PIO's with the style 1, style 2 ... classes you lose track of what they 'belong' to. At a least the PIO should give you options that mean something like for example stair tread x, stair stringer x etc. Even better would be the option to create a new class from within the PIO dialog box or the Object Info pallette.