Assemblage

Pat, attached is what I mean: design layer Z values are 3m and 6m respectively, but the elevation benchmark returns strange values

Screenshot attached of CPU and Physical memory usage when VP refuses to update.

Further: I'm assuming splitting the file up will not help, as a SLVP will still need to process the geometry whether it's coming from the file or a referenced file(s). Is this assumption correct?

[so as not to parachute onto Kens's "Minimum RAM memory" thread I've opened a fresh one here] When updating hidden line elevations, axo's, and section VPs in sheet layers I get this error: "One or more operations were aborted due to lack of memory", then: "The file save operation failed. Please try again, or save to a different location", after which the program crashes whatever I do. In case anyone understands such things, the crash Event log reads: "Fault bucket 1631980593, type 1 Event Name: APPCRASH Response: None Cab Id: 0 Problem signature: P1: Vectorworks2010.exe P2: 15.0.2.0 P3: 4b0e2827 P4: Vectorworks2010.exe P5: 15.0.2.0 P6: 4b0e2827 P7: c0000005 P8: 001ed148 P9: P10: " If indeed a memory issue, I'm already on 4GB RAM, so I can only increase the page file/virtual memory, however I understand Windows may be automatically doing this anyway, and it will actually slow programs down. Anyone tried this? Everything's in one file, 10MB, which doesn't seem excessive. It's a medium-sized medium-complexity 4 storey building. The worry is I'm still working on the shell, and haven't even started on the MEP or interior layouts, so there's a lot more information yet to go into the model. I can't issue drawings if I can't render hidden line SLVPs. It was alarming recently when I needed to issue a set of PDFs, and VW actually couldn't do this. Thoughts: - Turn off as many layers and classess as possible from the VPs (not really an option for Section VPs, where you're cutting through most building elements, despite limiting Depth Range to only a few meters); - Closing all other programs to free RAM; - [..Does VW cause a 'memory leak'..? ]; - Would unchecking "GDI + Imaging" help? - ...? I'll keep experimenting to try and find out more, but any thoughts are very welcome.

Could well be a memory/RAM issue on the local machine(s). I've noticed the "The file save operation failed. Please try again, or save to a different location" message then crash follows VW struggling with lack of memory when updating VPs. This would explain why you're getting it (i) when you have multiple files or programs open (which lowers available RAM) (i) following pdf creation, as VP will update before export (iii) despite no drop in server connection, as it's a local machine memory issue.

VW Help states: "Auto-Set Relative to Ref Elev : Uses the Y value of the elevation benchmark marker, minus the Reference Elevation value, to determine the elevation value." As can be seen attached Y=-4092 and Ref Elevation=0, so why is an elevation benchmark of -3545 returned? The benchmarks are being placed in a sheet VP via viewport annotation.

Shown attached: detail, and overall

Not sure it's that - it's greyed (attached). Ah well..just intrigued as to why

It's a good thing - as so many design architects know, so much is actually created 'from 1st principles'. Pre-formatted elements are only useful to a point, and then only sometimes. Sites, briefs, and clients are particular; assembled objects from limited kit-parts is closer to manufacturing.

It works - thank you! A weird thing however: unless class 'none' is left on, the floors don't appear, even though the floors (and the polygons they're based on) are in class 'materials-concrete'. I left the layers as is, so shouldn't be a layer issue.

Converting the Floor to a mesh object seems to give the same result..the Wall always appears 'in front'

Floor extends over the concrete block inner skin (as normal). How to make a Section VP show this..?

I copied the file, and then methodically deleted each class to see where the culprit was (including the VP). No joy. I then completely rebuilt the file, as well as the referenced file drawing in the VP, over the origin. It took a while, but the problem has gone - many thanks Mike. I was getting ground down...moral of the story: kick off drawings at the origin in the first place.

Any way of not having these? Is for a 1:20 detail section through a 4 storey perimeter wall...currently the break lines are appearing at the foot/head of each wall. 'Show wall components' and original object attributes are on, background render is set to 'hidden line'.

Just a minor comment: Pat's comment about editing the profile relationship to its locus is very useful. I've been working for years on the assumption that VW only EAP through the profile's geometric centre, which often has meant awkward manual calculations for the path dimensions to achieve a desired overall size for the extruded object. There's no way of knowing any different from the tool/help notes etc - why don't they mention this??

Can't get this DTM to appear filled. Only lines. Thanks in advance for any thoughts.

Tried all of those, as well as deleting all lights and deleting the glass texture altogether. I also tried opening the file on other machines. Still renders as attached..it's a mystery to me.

I didn't get any change by adjusting those settings..did you?

Still a problem (see attached). This is a fresh file, with elements copied across. Any thoughts very welcome

Yes, thanks. Reading together the Help entries on Hybrid Symbols and Screen vs Planar drafting, I eventually pieced together what was occurring. The somewhat perplexing thing about non-snapping the groups and path-extrudes is that they're a very common way of modelling door/window framing, and hybrid symbols are in turn often doors and windows.

Many thanks, I didn't know that. I'll rebuild the model on the origin

A final qual RW of a window now looks like!:

Hybrid symbols: is there any way to see the 2D info when editing the 3D elements (or vis versa)? Without being able to check one against the other, there's a threat to the integrity of a drawing set coming off the BIM model: a dimensioned top/plan may not reflect 3D sizes at all..

Hence 'Fast Renderworks' still works I guess. OpenGL not good though..

It is like it's gone through a Photoshop filter or something..is there such a thing in VW??