JMR

Thank you very much Benson. The methods you describe would get us closer to real 3D to 2D generation, albeit as you say, not quite what I'm after, but a better solution than manually cutting hatches etc. I wonder if I could make a vertical ceiling grid 1mm off the wall and display planar info in the viewport...have to give all these a go.

Hi all, I've set up a multitude of interior elevations in sheet layers. Everything works fine (though very slow...). However, I need to display ceramic tiles on some walls, and I since everything is created from the 3D geometry, I need to get the ceramic tile grid from the wall objects. I also need to adjust the run of the tiles by individual wall, since that is important for the builder (and the architect). I've run into the following when trying to crack this: Surface hatch cannot be adjusted individually? Controls are not available or they have no effect. Sometimes the change in eg. rotation of the hatch is passingly visible but immediately resets to the orthogonal setup, same with offsets Hatch controls change all walls' hatches, which is not an option, I need to adjust wall by wall Tiles or manual hatches are not an option, since I would have to cut holes for every shelf, mirror, tap, etc. in the elevations, by hand. If it were 2D drawings, the hatch could just go behind the objects in front Tiles don't export to dwg anyway - I cannot produce "as built" dwg's for the client with tiles Wall component hatch shows only in plan view, not in elevation (right?) Attribute mapping doesn't work with walls(?) Is there a solution for this? Any workflow advice would be much appreciated, also links to old threads. I did a search but didn't find anything directly about this.

Please vote this question up. Related to this is that eg. the window sill settings (and results) currently deviate so much from reality...enclosed is a section of a real window and window "sill". With VW I can get this far.... Oh my, can't help smiling now... 😂

@Matt Panzer We don't use any referenced VW documents, it's all in one file. The local distributor suspected the un-joining might have something do to with the wall thinking the style has been replaced even though it's not...don't know if this is the case. I can say for certain that one doesn't have to do anything that changes the walls in any direct or interconnected (slabs etc) way. It very likely has something to do with the PS commit/refresh process. We've had situations in which PC1 has nicely joined walls, and when PC2 and 3 refresh, their walls become disconnected, but in a different way! That is, one corner might be ok on PC2 but not on PC3. The only way to remedy the situation was to reshare the project from PC1. One thing that hinders tracking the bug-inducing steps is that it's not that easy to immediately spot some wall join becoming open in a complex building, since you have to zoom in quite close to be able to spot it. Then, when you notice it, it might already be a couple of days back when it actually happened.

Hi all, I think this bug hase been reported previously, but it's still there. The OIP dies = doesn't display the selected object, this happens occasionally. The remedy is to close the file and re-open. Any info on a correctional update? Thanks

The railings at landings are...nutty.

A dumb question maybe, but put the space object behind everything?

I've seen the same unjoining behavior with files that don't yet have slabs at all. But only with project sharing. Recently we started a native 2019 SP3 PS project and we're again seeing some walls un-joining. With 2018, the un-joining occurred without any wall-related actions, just doing something within the file. And the unjoining is not constant, different workstations display different results. An old thread here: https://forum.vectorworks.net/index.php?/topic/58706-possibly-the-most-frustrating-workflow-in-vectorworks/ This seems to be one bugger of a bug since it's behavior is so ridiculously erratic. No wonder it's almost impossible to reproduce, since we are only able to reproduce it by working continuously for several weeks on a PS project, and even then we have no idea what we did to cause it.

Exactly, I was a bit baffled by this. I had set all environment lighting to none. I have to give it another go.

I tried to use this with 2018 but in the end had to use classes. Great if it works now. We use heliodons since that way we can determine the right amount of solar shading for summertime. However, I've had some difficulty in getting consistent color with heliodons and different facades - even though there is no environment lighting, only the heliodon with proper rotation set.

I can confirm worksheet hopping, very strange. And at least for us, the display setting change removes the "hop".

On Best Performance, our worksheets are not visible all the time, especially at file opening. Sometimes they disappear and cannot be selected. Changing the setting to something else brings them back. This with 2019 Designer SP3. Weirdly, for 2018 and 2019 it seems some things work better with some display settings while others do not - there is no real constancy except overall the "best compatibility and performace" has fewest issues, IMHO. Edit: Also 3D orthogonal OpenGL views do not update properly; eg. changing a heliodon clock doesn't reflect in the view until one zooms in and out a bit.

If you draw a block (symbol) contents on layer (class) 0 and set their properties to "bylayer", the contents always inherit the properties of that layer, including line type, thickness, color etc. Therefore it's very easy to spot any block(symbol) residing on a wrong layer(class), since it always looks different. The only thing is to remember to keep layer 0 visible everywhere (otherwise your symbols can't be seen). BTW I remember having elaborate setups for aliases to avoid too much writing, like 1=pline 11=pedit c=copy cc=circle ccc=chamfer etc..

I've used Maxwell plugin with Rhino for ~10 years with great results.

First I thought you were speaking about record formats! 😁 There are those of us who occasionally venture into the dark side....not more powerful, but easier, faster... I've heavily customized the keyboard shortcuts, they do get one pretty far. The only thing is that when an employee asks for help with something, I'm completely crippled at their stock keyboard setup...they are wondering what is that old fart trying to do, pressing all the wrong keys constantly.

...And since symbols can't inherit the class properties automatically, it is very easy to accidentally put a symbol on a wrong class only to see that symbol pop up in a wrong viewport etc. I do miss layer 0 (and the command line)...

I'm rather surprised about we apparently being just about the only ones with DWG import speed issues. I've tried just about every possible setting and it always takes at least 30 seconds, more often 1-3 minutes for a 0,2-1MB HVAC DWG to import. And to update. If I want to update a set of references, it can take up to 15 minutes or even more. The speed issue is not particular to any project, DWG file source, type etc. - it's a cross-source issue. I'm starting to wonder if there is a setting we've overlooked if importing is effortless to others. As to referencing into another VW file, do you keep the DWG's as references or actually import them into the file? We keep the DWG's referenced since the modus operandi over here is that file names should never change during the project, the engineers send new files with the exact same name as before, the old ones are put into a directory named according to the date they expired. The same goes for our files we send out. The project cloud keeps the old revisions stored automatically.

You can right-click on e.g. 4.1, then "select item", then go to OIP data tab, select door record and "detach". However, it seems you have double criteria in your schedule, I think you only need either "type is door" or "record door is present". Currently the criteria selects all items that are either doors and/or have that record present. Try removing the "door record is present" and I think your "include in schedule" tick starts working.

Do you have "type - is - door" set? If no, try adding that. If yes, try removing the door record from those two unwanted doors.

It was someone called CS1, apparently not active since 2013. Probably others have figured this out too. Thanks Pat, that's a great idea since the ABS function is not available in the worksheet functions menu.

I had a go at this today. The problem with the length, width, height functions is that if the object is rotated, these values change. Please see: Another problem was negative extrusion values. In the end I used the following formulas in the worksheet: =SQRT(LENGTH*LENGTH) =SQRT(WIDTH*WIDTH) and to get the proper height for 90 degrees rotated extrudes =SQRT((VOLUME*1000000/LENGTH/WIDTH*1000)*VOLUME*1000000/LENGTH/WIDTH*1000) The silly multipliers are to get rid of the mm/m3 difference. The SQRT keeps the numbers positive. I guess in the end the above works for extrusions that are orthogonal to 2D plan, but not tilted.

Hi, I ran into a problem where a component list displays negative numbers for extrude lengths. How to get an absolute value? I'm posting this here since the thread where I found the solution is eleven years old: https://forum.vectorworks.net/index.php?/topic/23463-worksheet-function-changing-a-negative-to-a-positive/&tab=comments#comment-110335 Eg. for the length of an extrude, this always returns a positive (absolute) value: =SQRT(LENGTH*LENGTH) Brilliant.

I've nowadays set my undos to 20, previously I kept them at 50 most of the time. Didn't make any noticable difference, though. How large is a too large file - when should one start thinking of splitting the file into separate parts? Ours are usually 200-400MB, typically consisting of a ~2000sqm2 building with about 100 sheets. Here on the forums I've seen people quote working with files over 1GB, which to me seems rather large.

Unfortunately no. With 2019 SP3 I have to check this though - the update was very recent so too early to say. One thing related to this was, that for some reason, the referenced viewport class settings sometimes reset to invisible, thus creating the illusion of the reference disappearing.

Good to know. To the memory shoppe it is when the next pc update is due. One wonders if the code is quite right though, since the crashing. We've had similar issues with viewports. Setting everything to absolutely minimum and turning off all possible classes helps with the speed. Still too slow though. Current machines are 16 and 32GB.