M5d

It looks like we're getting depth of field, as part of a much improved renderer.

I've never been able to work out which, when or why some functions, other than the eyedropper, manage to change / set attributes away from their 'by class' settings. Could be something I do, could be a bug I don't know, but I would like the 'make all attributes by class' selection to lock the attributes palette in that state, or for there to be a lock switch on the attributes palette that prevents attributes inadvertently switching off of by class, or a selected set of attributes, without consciously being unlocked first.

I wasn't sure about your question above, so I edited my post to refer to DLVPs and SLVPs separately. I can't see the option, you've mentioned, that layers two render modes as one in DLVPs, but then, I'm not familiar with working that way I've always stuck with Sheet Layer VPs. Maybe someone more familiar with your workflow will be able to help.

They are available for Hidden Line only renders in DLVP, and available in the 'Foreground Render Settings. . .' for layered renderings in the object info for sheet layer viewports.

This isn't the cause or a good solution for an error, but when I can't find anything incorrect in the geometry, I try adjusting the 'Smoothing Angle' up (15º, 30º, 45º, 60º, etc.) for the Hidden Line / Foreground Render Setting and it often removes unwanted lines like these. Also, if you're using 'Generate Intersecting Lines' try tuning it off.

Are you referring to integrated exchange, i.e. exchange that reads, edits and preserves native information as it's circulated back and forth between applications?

The CPU monitor made it look as though 4 cores were active, just all throttled down.

Jim, any clue what causes the very long calculate times on the wall material worksheets above? Even a small residential project sends Vectorworks into a catatonic attack of spinning beach balls, but watching a CPU monitor while it's working only shows moderate activity (25% or less on any one core).

Had a go at reducing the calculation time by offloading the calculator for a by component approach. Only the layer controls are hidden now. It seems faster, but you'd only want to introduce the calculators at the very end for take-offs. Component names go in A3 through A12 of the Wall Material Quantities Schedule and the layer references go in L3 through L12. The calculators reference the component name fields via K1. For a second material, duplicate Wall Calcs-Component 1 allowing its name to increment naturally, (i.e. Wall Calcs-Component 2 and so on) then edit cell K1 to reference the next component cell or you could just set up 10 calculators in advance to drop in as required. Beware, I haven't tested it thoroughly, though I have found both parts need to be recalculated separately, calculator first, before they sync.

Yeah, I would have used undo each time the wrong column pulled out. I wasn't aware of the bug.

That’s interesting; I can’t even drag open the input columns K & L in 2015 (SP1 – Australia) without it crashing. When I opened your edit though, it didn’t crash. I haven’t tried separating the database, but I don’t think it would resolve the problem with calculation time. I don't see why this task bogs the CPU down so much, you'd think it would spit data like this out in a blink.

I've been promising this to a couple contractors for years, so I had another crack at manufacturing a worksheet out of the existing functions yesterday. It's a crazy worksheet that emphasises the problem, but it can search walls of up to 10 components and extract their component areas (NET) by name, ignoring all other factors, and compile that data into a single area for each named material. I created it in 2013 and it works (in theory), but it totally chokes Vectorworks up and takes ages to calculate in a real file. I thought maybe 2015 would handle it better, but alas, it just crashes 2015, even in an empty file. If you want to try it out in a clean or simple file (not 2015), open columns K & L and enter a component name in one of the search fields of column K inside quotes (one of the ='N/A' fields) and then name the layers to search in column L. Vectorworks has a few problems, WALLAREA_GROSS & WALLAREA_NET are not accurate for component takeoffs if wall components have level offsets. We need COMPONENTAREA to divide into COMPONENTAREANET and COMPONENTAREAGROSS, and we need the criteria field to accept either a component number or a name as Vincent suggests. i.e. COMPONENTAREANET(criteria,index) or COMPONENTAREANET(criteria,'string') & COMPONENTAREAGROSS(criteria,index) or COMPONENTAREAGROSS(criteria,'string')

Can't comment on your specific problem, but in general, it's advisable to keep your older versions installed.

It's the same under Mavericks. Under OS 10.9 VW 2013 can use that key combination fine, but VW 2015 reports that it's used by OS X, same machine, same OS, same settings.

Yep, it's the brick shader. So defaulting to OpenGL is only reliable with image based shaders?

Low quality only OpenGL bug? This is how OpenGL renders at low quality . . . It's not very usable. And this is how OpenGL renders at high quality . . . Does design layer rendering need some other setting changed to improve how OpenGL renders?

Submitted a 2015 bug yesterday, only to find that I couldn't get the behaviour to repeat in a new VW session and file today. A tried and true fix I forgot, before wasting everyone's time. This is the better place to raise "potential" bugs and see if they're a real issue or something user generated. Productivity could really be aided by bcd's bug submit forum to investigate, report and follow up on the progress of bugs in one place. I wonder how many bug submits are duplicates, misunderstood or non-issues? Jim's making a gallant effort, he's become the forum, thread and post Bugs Bunny trying to catch every potential bug question, but it seems highly inefficient and how can the rest of us follow along? Maybe a sticky topic called Bugs?, until something better is agreed to by the reluctant powers saying no to the request?

Use world Z is on. Displaced both directions.

I think gmm18 was onto a bug. I set up a basic texture with a hatch, aligning the hatch inside the texture doesn't render that way on an object. Displacement occurs in either direction, vertical or horizontal depending on the texture.

Yep, that looks like a different issue. The grid issue is easily fixed, if anyone is wondering. For it, just make sure the 'Print Grid' option in the smart cursor dialogue is unchecked. If that option is checked, lines like those in Benson's shot will alway occur on PDF exports, whether your screen grid is hidden or not.

Have you got your grid lines turned on? On a sheet layer at 1:1 scale it generally puts a central horizontal and vertical line through the page.

I think you might be discussing two issue's here? Jim is addressing adjustment inside the texture and then there's texture alignments in use. The in use issue was just discussed in the Renderworks forum. Hopefully we'll get a fix in the form of a "Use World X & Y For Origin" button in addition to the "Use World Z For Origin" button. The difficulty of getting stacked elements to align and stay aligned when edited really needs a fix now that we have 3d hatching. With full textures you could often get away with some misalignment, but 3d hatches will not be forgiven by the eye in the same way.

Yes please.

I think you may have asked for this before mike, but anyway, and / or add a drop down option to the height section in the wall OIP to select wall components needing individual adjustment overriding their style settings.

That'll do nicely.