Rick Berge

@E|FA, For Stairs, go to the Graphic Attributes and choose one of the 3d portions, not the 2d. Then the dialog that pops up does have material controls. Railing should be the same. Hope this helps, Rick

Correct. As far as I know there are no alerts and it all works just fine inside the same document. Stacking viewports, cloning sheets, etc.

Hey all, Pasting viewports between documents was a source of file corruption. (And this is only about between documents). There's been an Alert forbidding it for a really long time, and we didn't realize the impact of closing some of the remaining loopholes, didn't realize that users required it. There is a bug open to replace the now-missing workflow, and we'll get this addressed.

Thanks both! We'll get that taken care of in English too, and that generally triggers all the localizers to look again.

Almost everything on Jim's summary wishlist for Materials was implemented in VW2021. I can only count three of twelve as not done, and more accurately say that every single one of them was addressed but those three are more that the responsibility has stayed put and materials didn't need to do anything extra special, yet. 5) Materials must include Line Styles for both the 2D and 3D edges of geometry, separate control for section vs non-section views. Pens seemed most naturally to stay where they were, controlled by walls/components/LOD settings, and only give the appearance settings for surface/section fills and texture to the material. 9) It must be possible to generate reports on the volume, weight, density, cost, surface area, exposed surface area, and thermal properties. Components have surface area calculations, but if you consider the full suite of interesting ones (full WxH face, that minus window cutouts, that plus wrapping the edges of the cutouts, etc), components are not calculating all possible ones. Materials have what components do but more would be nice. (Also, more and better linear measures.) We still have those as wishes on our plate. And easier reporting too. 11) Materials need to (optionally) have the ability to determine the joins for wall, slab and roof components contextually. Each of these types of joins needs to be user definable. For now this is still components, and little to do with materials. We do have component wrapping and joining in our sights, and at that time we'll reevaluate if materials need a special role or not.

Hi @matteoluigi. VW uses a slightly different syntax than excel. Try sum(A1..A20)

Not sure when it started, but for a while now the wall has context menu items for creating a style from the wall, or locating/editing the style if it has one.

Understood, and thanks. I'll mention it to the University people (Tech Support and Training), and take another pass through the help to see what can be done there.

It's not all that complex. Remember this is all about the object (or component) to which the material is applied. 100% is that whole object. If you report on something volume-based, it's 100% of the volume the object claims to have. If you report on something area-based, it's 100% of the relevant surface/sectional area the object claims to have. These are the same as what you'd see in worksheets for the object, e.g. =volume. If this is a wall component, area is essentially the surface area of the wall component's face, or the top surface area of a slab or hardscape's component. 100% is that whole surface. If you say some material is 50%, we don't care what half you mean. That could be 50/50 alternating brick colors in a pattern, or left half paved/right half metaled. Volume could be a mix (like concrete and rebar) or some sort of striping (concrete in steel decking pans?). We're not modeling the "framing" of how the rebar is installed and calculating linear feet * cross section. This is googling 'percentage of steel in concrete' and getting an estimate. You can adjust the estimate until you get what you want, and you might very well need to do that based on the size or nature of the steel (#3 - #5 rebar, mesh guage, etc) and what's being reinforced (slab, column). You can set a material to report as area-based, volume-based, or both. Often only one will make sense. E.g. surface area of insulation board or batts to calculate BOM.

Oh, and nothing says you can't use a simple material to represent something more complex. In the insulated-siding case, the Component approach will put both appearances in your drawing. The Compound will not. In some ways using a simple material might better model a manufacturer's product: siding that happens to have the right lambda for the insulation.

Part of this gets at the old dilemma of how do you model, and how much do you model. For things like concrete and reinforcing steel, we wanted to keep them independent from each other volume-wise so that if you were happy with the concrete report, you wouldn't have to risk messing it up to get the steel report correct. Like you would if it was 98% + 2%, had to total to 100, and you were forced to adjust one to adjust the other. It's not terribly realistic for multiple 100% volumes, but we want to stay out of your way to do what you need to do. Area-based is more interesting. Consider something like insulation-backed siding. You could model this as a compound where both the insulation and the siding are both 100% of the surface area, and this makes complete sense. Or you could model them as separate insulation and siding wall components, each with a single simple material. It's fully in your control to do either. Again, the compounds give you the ability to throw additional reportable bits in later without screwing up any of your visuals or existing reports.

This was a content bug, and it's been reduced (I think to 2%). I'll make sure there's a bug for this.

I'm sorry I didn't find this thread and weigh in earlier. Because of the million years of how people expect Plan view to work in VW, applying solid fills to things has always meant surface color, and hatch fills has always meant cut appearance. So the material's Fill is its cut appearance. Surface appearance comes from the Texture and the texture's Surface Hatch if any. Materials work perfectly fine with sections and horizontal sections. In fact, nothing has really changed here. The material provides the hatches instead of the class, but it is still the viewport deciding how it is cutting objects (cut, not, above/beyond) according to all the usual settings, and provides the pen in the usual ways. We think the pen is due to the context and purpose of the drawing and object. Very few places does the pen depend on the specific material ('concrete'); instead it's almost always the purpose ('component-structural'). This is how we were able to shrink the component classes down to 4-5 representing component's function, and why pen is not in the material itself. For overrides, classes can still override the pen. Or the rest of the appearance if materials are set to use objects' class. DataVis can also be used to override appearance of materials and classes, and you can combine DV and class overrides in a single viewport. Or stack viewports, or whatever your workflow is. We tried not to take anything away (except too many classes!) and give you more tools. C, I know Matt and Chris talked with you about trying to make Plan look like horizontal sections. If that must be your workflow, I think your best bet is making materials that are set to use objects' class attributes (or to not use materials). A simple script can zip thru and change all their fills/textures to by-class. You won't benefit from the simplified class structure, but I believe it will be the same result as the old fully class-based system, and you'll still be able to do material reporting without it affecting appearance at all.

I don't think so. I'll mention this to the Markers team

Thanks for catching this @drelARCH! I've filled in all the selectors now. Take a look and let me know if you think there should be anything else.

Thanks for reporting this Kevin! We were able to narrow this down to something corrupting the text size preference (from plugins that span multiple layers like title block manager or markers). It's been fixed for SP1.

Hi @line-weight, Current code has changed a lot since then, so unfortunately I'm having trouble finding any workarounds for you. It seems no one had filed a report on this until 2020sp2, so it was fixed in 2020sp3.

Thanks for finding this. We found the problem and fixed it for the fall release.

I think that is one thing accidentally lost in the change from a live Summit to this year's individual collection of video presentations. It was easier this year to look at a few frames in a collection of videos and for both speaker and listener to gloss over a phrase of "in the future" in any of them. Versus the usual Design Summit with more time allocated to a single "roadmap" session, where each speaker had a longer introduction and the whole is set in its context. We're always excited to share these details with you and see how our planning is received, and it was just as important to do a different kind of "first" and find some way to bring this to you with all the other crazy that's going on in the world today. Thank you all for the feedback that you like what we're trying to do.

As a workaround, it looks like it will still take the fill (and/or texture) from the class. It's only the Attribute Palette getting in the way. SP2 beta that I tried seems fixed with the Can Top example.

As a workaround, it looks like it will still take the fill from the class. It's only the Attribute Palette getting in the way.

Wish delivered in 2020! If a particular visualization scheme does not apply to an object, "Draw all other objects: Normally" will now fall back to whatever the viewport wants, class overrides included.

One question here is if it is ever appropriate to show the old view. E.g. you have autosaves triggering after 10th action, and you happen to be zoomed in on some little thing. Or whatever. Thanks for the feedback!

If it makes you feel better, I don't quite understand it either. I think it may be temporarily strange until the tech that was developed for the live section views can be implimented outside that one editing mode, which we do plan to do. Think of it this way...we can do the fake mode directly in the VGM specifically for the cases we wanted (edit section), or we can spend a lot of time making an official new render mode that shows up in all menus everywhere, viewports, save/restore view, gets stored with the file, reverse translation to older files, on and on. We talked about making it a new mode but simply didn't have the time for all the extra work.

Is this not the same as the 'Export PDF' options to 'Rasterize'?