Jump to content

Tom Klaber

Member
  • Posts

    2,005
  • Joined

  • Last visited

Posts posted by Tom Klaber

  1. We are looking at moving more schedules to online shared resources.  This collaboration with contractors, clients etc. is super helpful. Right now we have to have all of our automated schedules as stand-a-lone Vectorworks worksheets, and shared schedules like finish schedules as google.  It would be great if we could export and import google sheets to directly sync and overwrite the shared files. 

  2. I clearly do not want to work today...

    @zoomer
    The reason the other programs misuse the term "layer" - is because of Autocad - not because of anything innate.

     

    Layers - are analogous to layers of vellum - the place where objects are drawn.  They can be stacked (or not) but can - if you wish to have a stacked relationship with each other. 

     

    What do you do with classes but to classify the objects?  Either at an object type or an option a or option b... ?  Honestly curious to understand how else classes can be utilized.

     

    While you might have some outliers - classes do classify objects - and are analogous to your pen set - as they define the visual appearance of the objects.   Your layers do not need to have a layered wall height to take advantage of their stackability.

     

    Would you really advise switching their meanings? Do you really think that makes more sense? Do not believe it. 

    • Like 1
  3. 47 minutes ago, Jeff Prince said:


    as a former long time AutoCAD user, we use(d) xrefs in the same capacity as Vectorworks Layers.  I prefer Vectorworks obviously, but the VWX naming convention does conflict with most major softwares, hence confusion.

     

    @Tom Klaber For rendering, Materials is a term that is inclusive of a Texture map, but encompasses much more such as how the material behaves in different lighting, rendering, and physics engines.   A Texture is a small, but very visible, portion of the definition that defines the look of a Material, regardless of what people name their websites 🙂   Look at technical education and most books published on rendering prior to YouTube hacks ruining technical language… Materials is the correct term…

     

    XREFS are not quite the same as layers - but I hear you. Convention aside - I really do think that Vectorworks - despite being in the minority - is actually using the correct terminology in the grand layers/classes debate.  I say we stand our ground - righteous win out. 

     

    I am so baffled by this.  Vectorworks has Materials.  Just not sure how renaming "Renderworks Textures" to "Materials" is a step in the right direction.   I never hear people say they have to go "re-material the model" - they have to go "re-texture the model."   Do you take your Vectorworks models into physics engines? 

     

    We use Lumion - and they - as you say - call these resources Materials.  Maybe I am just used to it - but have not run into this as a sticking point.   Each own. 

  4. 20 hours ago, zoomer said:

    From a rendering term,

    a VW RW Texture is a "Material",

    which can have applied procedural or image "Textures" inside

    the "Material" channels like Diffuse, Reflection, Bump, .....

     

    And a Render Material does describe the rendered appearance

    of a Material basically in the same way as BIM Material data

    does for a Building Material.

     

    E.g. if you have a 3D App and go to dynamics, you may want to

    have additional drag coefficient information for that Material too.

    No matter if, for organizational reasons, this is stored by material

    or by object, it is additional information data.

    Just like VW building materials may include additional "RW Texture"

    definitions for the render appearance.

     

    And the whole reason I always asked VW to bring  a "Building Material"

    System was to avoid to need to manually re-enter the same concrete

    every time again whenever you create a new concrete component

    in a style.

    Nevertheless such a Building Material should obviously also contain

    the render related definition.

     

    So from a VW-only perspective, it may be ok to agree to VW Materials

    and stay with separate RW "Textures".

     

     

    But from my global 3D and CAD experience those VW terms don't make

    any sense. Literally.

     

     

    To avoid Babel Tower problems, there are trends to explicitly standardize

    terms and there is a quasi standardization that comes simply from common

    usage and collaboration.

     

    And this is where VW, in the past just failed.

    It is just VW that brought the term "RW texture" for instead of Material

    for whatever reason or just arbitrarily or pure ignorance.

    Same as calling their Layers "Classes".

    While any else CAD, even when having a similar double order system like VW,

    uses the term "Layer" (which makes as much sense as VW's classification).

    And really everywhere in Computer Graphics,

    a VW RW "Texture" used the term "Material" but "Texture" for a surface description.

     

    Every other 3D or CAD App or anything in between I have used or seen so far,

    uses the term "Material" for the grouping overall description of render properties.

     

    So I think it it is definitely the same, Render Material vs Building Material,

    physical values like k-value, weight, .... vs light absorption, fresnell, color, ....

    it is just about prioritization of which data is relevant in which kind of App.

     

    Beside all 3D Apps, even any other CAD Apps that I know call

    "VW RW Textures" Materials ....

    Microstation, Allplan, Autocad, Bricscad, Freecad, Archicad, .....

    maybe even chief architect (?)

     

     

    From a VW-only point of view that may be all impossible to change and somehow ok,

    from my point of view that is all unnecessary and deeply wrong.

     

    I see and help with some ACAD to VW switchers posts on these forums having

    problems with VW Classes. Which is not really necessary.

     

     

    As said, I can live with this VW nomenclature pretty ok.

    (RW Textures, Materials, Classes+Layers, Stories, Jambs+Sashes, ....)

    It is just that I still think that my arguments are valid and that I will not change

    my mind that some is completely wrong and making many peoples life more

    complicated than necessary.

     

     

     

     

     

     

     

     

    Oh Zoomer - we have never been so opposed before.  While industry standards are all fine and good - doing something just because that is the way AutoCad does it is not good enough.

     

    Autocad "Layers" is a bad name for that that is. The term "Classes" is more accurate to what they are. The fact that VW has this dual organizational system is one of the most profound advantages it has over AutoCad. Classes are classifications - layers - like a cake - can have Z relationships.  You are dead wrong about wanting to follow AutoCad there - even if others have. 

     

    "Textures" has always been the industry standard for a map that gets applied to an object for rendering.  WWW.TEXTURES.COM - formally CGTEXTURES - is one of the best resources.  If you go to Poliigon - they have "Textures, Modesl, and HDRIs" - nobody calls the image maps you apply to objects "Materials."  "Materials" is more of a BIM term meant to classify objects with material-specific data and attributes. What if you wanted to change the look of the concrete in your model?  You would not say that you wanted to change the material - you want to change the texture that represents the material.  They are different.  Vectorworks has materials too - I do not use them - but if you make a material you can assign a texture to represent that material - have no idea why you would want name both those concepts the same thing. 

    • Like 4
  5. On 9/14/2023 at 4:54 PM, zoomer said:

     

    I personally would think it is logical for Render Materials and Building Materials to be combined,

    but I have no problem if they stay separated  for organizational reasons.

     

    I just still think RW Textures should not be called Textures but Materials as everywhere else.

    And as VW meanwhile got "Materials", I see a need to differentiate both naming.

     

    I agree with the initial wish of simplification to Sheets and Layers (SVP and LVP ?)

    but not so much with "Textures"

     

    But I am not a standardization authority and scale for everyone, I just put it in.

    Basically I got used and can live with Classes, Layers, RW Textures, Jambs and Sashes, ...

    Right now Textures and Materials are not the same thing. A texture is a rendering term about how something looks - the idea of a material is broader and that it comes with more data. You need those concepts to be different.  

    • Like 1
  6. 2 hours ago, _James said:

     

    Not sure if it's the same in US architecture but this statement is dangerously close to the "you should be in by Christmas" jinx of UK residential architecture. If a contractor or consultant utters these words to the client it guarantees a fatal catastrophe that delays the project for many months.

    I have not heard it spoken - but yes - we very much have this same curse. 

  7. Again - loving the new drawer style pinning mechanic.  But everytime I open VW - the resource browser resets to:

    image.thumb.png.0029c28e37caef13749a7ed15076838e.png

     

    I then have to slide out the deferent columns to my preferred width.  Would be great if it could remember the positions rather than defaulting to what looks like min, min, remainder.

     

     

    • Like 2
  8. 21 hours ago, Tom W. said:

     

    It is by style. But edits to the style take effect by replacing the Wall instances in the drawing. The same with Slabs + Roofs. And in all these cases you have check-boxes which allow you to transfer all of the settings over or leave some of them as they are. So just make sure 'Replace data' is enabled by default + all Walls in the drawing will always respect the changes to the style.

    I mostly get that - but the Mark data is not really by style - there is a mechanism to transfer the data - but if you do not have that box checked - you could have 2 walls with the same style with different marks.  If there was a true by style control of the mark - you could elect to eliminate that failure point.  It is easy for me to imagine that somebody in the office does not have that checked - (despite the email I will send this morning) - and replaces the walls - not realizing that the tags will not update. 

  9. Not mentioned anywhere is a great new feature of being able to dock closed tool pallets that then roll out on mouse over.  I love this in principal - no more lost Resource Window.  I love how it also rolls out on the CMD+R command.  Great new feature...  But...

     

    The animation is janky - studdering - feels and looks terrible every time.  Not sure what the programing behind the scenes looks like - but if that could be a smoother action - it would go a long way to having this feel polished.  

  10. I really need the Wall Mark to be controlled by style.  It seems right now - if I change the wall type - the Wall Mark does not update - leaving the tag reading incorrectly.  This obviously negates one of the biggest benefits of using styles is not having to manually check all the tags. 

     

    Am I doing something wrong?  Is there another field I should be using?

  11. Agian - loving the new UI.  There is one wierd thing on Windows where the OK button / and sometimes default YES option is grayed out and looks as if it is not clickable:

    image.png.3c3352eb267172fee88d7ae23ff5eb1c.png

     

    I have come to realize that it is just selected - but the it is the same look as an unclickable button.  I think we need a darker shade of gray - or a slightly different look for a selected button.

    • Like 1
  12. 2 minutes ago, zoomer said:

    I only have a problem with Textures.

     

    Coming half from the 3D App side, the term texture is always used for image textures.

    While VW's RW Textures are commonly "Materials".

    And Textures are a child part of Materials.

     

    As we meanwhile also have Building Materials, I would rather name these BIM Materials.

     

    I also have a great problems with VW Layers as anywhere else VW Classes are Layers.

    But as Classes for classification makes some sense and Levels may not really fit to

    VW Layers - I can live with it ....

    The confusion with Layers and Classes as it applies to communication with AutoCad will exist regardless - no desire to make the internal VW nomenclature clunkier to somehow better fit with other programs termonology.

     

    Not sure if I understand the hesitation around Textures vs Renderers Textures.   Materials are a broader concept that contain lots of information including textures.  To me - dropping the word Renderworks does not change anything. 

    • Like 4
  13. Yes!

     

    I am playing around in 2024 - the new UI feels great - but the attributes panel is little changed.  There is room for great improvement here.  Just the way a hatch or tile is previewed in that long skinny box with the name over it - not great:

    image.png.196c563de756cff7fd19012346aa06c8.png

     

    I think the suggestion of having a quick all by class button is a great idea.  I think a better layout in general should be investigated - with a better preview.  Maybe have a full lager square below that previews the settings. 

    • Like 1
  14. 19 minutes ago, line-weight said:

     

    Yes I see, you are right of course.

     

    I guess I have not previously paid a lot of attention to what happens when I bring in a style resource to a different file - whether classes that are part of it (but not present in the destination file) get imported or default to something - and whether the behaviour is consistent between different types of styles.

     

    I just tried importing a structural member style to an empty file, and I see that the class that is attributed to the SM comes in with it and is added to the classes already in the file.

     

    But a set of (possibly hundreds of) class visibilities/over-rides for a viewport style - that's slightly different because it's not objects in the classes themselves you'd be bringing in but a set of rules about how they appear, which is all rather more complicated to co-ordinate. For example if it has a rule about a particular class, which isn't in the drawing that I am bringing it into... then does that rule just disappear or does it get remembered if I later add that class to the drawing?

     

    But we will find out in due course.

     

    Our internal desire  - is to have the same or mostly the same classes across all of our projects / files.  Every project usually gets a couple of special classes to sort something out - but the majority of it is standardized.  Additionally - we have template files with the starting official office standard classes built in - so the viewport styles could be predefined and contained in your template.  So ideally you would not be starting from nothing.

     

    Speculation here - but my guess would be that the style would simply try and translate as best it could at the time of being imported.  If there is a class definition that does not exist - then it is simply ignored and new classes are defaulted to off. I would not imagine that if you added a class later that it would default to on - even if that style in some previous version of its life in a previous document had it on.  You would simply need to redefine the style if you add classes after the style is imported.

     

    Without class support - the viewport style is not of very much use to me...

     

     

    • Like 1
  15. On 9/7/2023 at 4:36 PM, line-weight said:

    I don't quite see how control of class or layer visibility could be part of a viewport style. Because styles are independent of individual files, but two files can have entirely different sets of classes.

     

     

    Class settings are part of most styles.  Custom classes and definitions for doors/windows/tables styles - and they work - I think they just default to <Door Class> if the class in the new file is not present. 

     

    It could be that the layer and class settings aspect of the style is localized to the file that the style resource is.

  16. 13 hours ago, Matt Overton said:

    I'm hoping at the very least it gives a central location to control classes of all viewports of the same style. That would be a big day one win, then we can test the edges.

     

    Yes - 

    My biggest pain point is the addition of a class or a class modification to a viewport type.  Then having to go and paint bucket those new settings on the other viewports - is error-prone.   


    So looking forward to never hearing again: "Why isn't P-Risers-New" not on the second floor RCP?"  

    • Like 1
  17. We have this problem all the time.

    Very frustrating - we have learned to work it into our time estimates that we will have to retexture the Lumion model 3 or 4 times while preparing a presentation.  We have learned to save the lumion textures we create to speed up the process of re-applying - but still nothing worse than having to redo the same work over and over.


    Best,
    Tom

×
×
  • Create New...