Jump to content

Christopher Graye

Vectorworks, Inc Employee
  • Posts

    290
  • Joined

  • Last visited

Posts posted by Christopher Graye

  1. 7 hours ago, Tom W. said:

     

    Could you confirm whether this includes or excludes Walls/Slabs/Roofs? Thanks.

     

    No, not walls, slabs, or roofs, which are not plug-in objects, and for which the Attach Record context menu command was never present.

  2. The Data Manager is certainly the most powerful way to do things like this, and it is our recommended workflow for dealing with project data, so I hope you will take the time to explore it if you have not yet.  But we have also now done the work to properly implement the Attach Record context menu command for plug-in object styles.  It will now work with all plug-ins (instead of just some), and it will also be able to attach records to existing instances instead of only to newly created objects (in other words, it will work the same as it does for symbols).  This will be coming in Vectorworks 2024 Update 4.  Thank you for all your feedback on this issue!

    • Like 3
    • Love 1
  3. 7 minutes ago, Tom W. said:

     

    If you set up the data mapping so that the Record is attached to objects by class, you can define the mapping for the Record fields on a class by class basis. This requires you to create different classes for each of your Door styles + assign the Doors to those classes in the PIO Style Options. When you insert a Door in the drawing it will automatically have the Record attached to it with the fields filled in as determined by the data mapping for that class.

     

    It would be great instead if you could define the mapping on a style by style basis but I'm not aware that you can do this.

     

    It should be possible to do this, though I am far from an expert on the Data Manager either, so I'll have to play around with it and try to figure it out.

     

    In the meantime, I am also checking into what would be involved with adding the context menu command back in such a way that it works reliably for all plug-in objects.

  4. @KWiley, interesting.  One possibility is for us to do the work necessary to make this work for all PIO Styles, including propagating the record to existing instances - in other words, make it work the same way as it does for symbols.  But that still seems pretty limited.  Isn't it a huge problem that you cannot make edits to the door style record after the fact and have the changes propagate to the instances?  The same could be asked of symbols, too, but it seems much more limiting for PIO Styles.

  5. On 12/8/2023 at 2:32 PM, KWiley said:

    Yes, I updated as soon as it came out. I was right in the middle of customizing my door file when the first problem with the attach record happened, I reverted back to update 1.1 to finish what I was working on. After running into the door glazing issue and the column issue this morning I went back to update2 and all 3 problems are still there. I submitted bug reports on all 3, the attach record bug has been confirmed. The other 2 I just submitted this morning. I'm currently downloading 2023 again so I can actually get some work done. 

     

    The Attach Record context menu command is still there for symbols.  It was deliberately removed in Update 2 for plug-in object styles, because it was never supposed to be there in the first place.  This was brought to our attention when we got a bug report about about records attached to structural member styles not being placed on new instances.  We had no idea this command was even in the context menu for plug-in object styles.  It turned out that it got there because symbols and plug-in object styles share some implementation under the hood, and the code that builds that context menu was not properly distinguishing between the two.

     

    Since the records were not getting attached to the instances anyway, we just removed the command and thought that was the end of it.  But apparently there is more to the story, because the records in fact were getting propagated to doors and windows from their styles, as mentioned in this thread.  So we looked into it more, and some plug-in styles, depending on some technical specifics of how their corresponding tools are implemented, actually do the records, and some do not.  There is no way for users to tell for which kinds of objects this will work.  But at least some users have been using this for doors and windows.

     

    How exactly are you using this for doors and windows?  The accidental exposure of this functionality only worked half way for objects for which is worked at all, so I'm surprised it was useful.  For one thing, unlike symbols, when you attached a record to an object style, it would not be placed on existing instances.  Also, when you edited the record fields on a style, it would not update the instances with the changes, so there was no way to make any meaningful changes after the fact.  Basically, we have to decide what to do about this now, and I am trying to get an idea for how this was used in your workflows.

  6. 4 hours ago, line-weight said:

    I assume these are automatically generated when you do it within a window object.

     

    I wonder what happens to wall closures if you make a custom symbol of your own, and define your own wall hole and make it non perpendicular to the wall.

     

    I had better get on with some real work now though.

     

    Right, plug-in objects generate their own wall hole and wall closure geometry based on what makes sense for the current parameter settings.  For symbols you have to provide these explicitly if the default behavior does not work for you.

    • Like 1
  7. 4 hours ago, Tom W. said:

    Do you mean in the Wall Closure dialog for a Window? And a basic door representation when the insert is a Door? What about when the insert is your own symbol? Use the generic grey rectangle in those cases?

     

    The thing is, though, we don't know, in general, what kind of object is in there.  It might be a plug-in object developed by someone to represent a door, but all we would know is that it is a plug-in object - there is no way for plug-in objects to tell Vectorworks, "I am trying to represent a door".  This is another case where if we designed wall closures to interact only with our own doors and windows, we could have created a more focused experience.  But we needed to support any plug-in object.

     

    4 hours ago, Tom W. said:

     

    What I am still confused about is this:

     

    Untitled.thumb.jpg.6629e3141e990581e08b8573caba8be5.jpg

     

    @Christopher Graye this suggests (as @line-weight said) that in the case of the Wall Closure dialog for an insert, the preview shows not a generic insert but one that has the depth + origin of the insert in question. This isn't what happens so are we misinterpreting what it's saying? Or is the info incorrect?

     

    That is definitely not correct.  Possibly it was added when we were trying to do this and never changed later.

     

    4 hours ago, Tom W. said:

     

     

    I think for a symbol you can define exactly how you want the wall to interact with the symbol by adding geometry to the Wall Closure component of the symbol (have never tried it).

     

    https://app-help.vectorworks.net/2024/eng/VW2024_Guide/Symbols/Adding_a_wall_closure_component_to_a_symbol_definition.htm

     

    Yes, this is where you provide the geometry the wall closure interacts with.  This is necessary because there is no way to know which parts of the 3D geometry to take into account and which to ignore when it comes to the closures.  So you just make it explicit here.  If you leave it empty I think it creates a flat plane at the symbol origin to interact with.

    • Like 2
  8. 4 hours ago, line-weight said:

     

    I'm assuming that the preview creates a basic cuboid type object, because there are in the end only 6 planes (exterior/interior, 4 sides) that can interact differently with the wall, and its those 6 interactions that the preview tries to show? And the complexity of the insert object itself doesn't change any of that, or does it?

     

    Reason I ask is, would it not be possible to draw a basic 2d shape, that resembled a window, in place of the grey square, in what is shown to the user.

     

    Maybe, but if you are not actually putting a window in there that will be misleading.  I think I actually wanted nothing in there all, because, first of all, I didn't want any detail at all to obscure the actual closure geometry the user is editing; and secondly so everyone understood that they were editing the closure, not the inserted object.  This was a major point of confusion at first, because everyone was used to controlling component wrapping by editing the inserted object itself.  But here what you are editing is the wall or wall style or, at the insert-level, the connection between the wall and the inserted object.  So by de-emphasizing the graphics of the insert, I had hoped to make this clear.  Matt, I think, thought we needed something in there so that the options about wrapping to the insert, etc. would be more clearly understood.  This dashed gray rectangle is the compromise we came up with.  And it has gone through some changes, too - I think it was initially much darker.

    • Like 2
  9. 19 minutes ago, line-weight said:

    When I first met this interface there were two things that confused me. One was the fact that the preview requires some manual input of data and that changing settings here doesn't change anything in the drawing. But there's not much to signal that to the user. That's not something that really occurs elsewhere in VW (that I can think of) so I think there could be something that makes it more immediately clear what is happening. Some cursor prompts do appear in small text when you hover over the settings, but could that text not be written immediately above the input fields?

     

    These preview controls were actually not even in the initial version of the feature.  They were added later (I think in a service pack).  I remember having the same thoughts as you regarding the text above the input fields, but for some reason I did not win that debate.  I think it was deemed sufficient that the controls were inside the Preview group box, and that users would understand that those were just controls for the preview.  But I don't remember exactly.

     

    19 minutes ago, line-weight said:

     

    The other thing is the "grey zone" that appears in the preview image. This represents the region where the "insert" will sit, but I spent some time thinking it represented a depth zone between the outside face of the wall, and the outside face of the inserted object.

     

    That's partly because "insert depth" (where I'm invited to type a number) could be read to mean the depth of an inserted object or the depth at which an object is inserted. In fact I have to confess it's quite hard to think of an alternative name for this field that is unambiguous. Hence I'd wonder if better graphical hints could help.

     

    I appreciate that in some cases it won't be a window going in here but could be some kind of custom symbol. So perhaps that's why it's just shown as a "grey zone" rather than something that looks like a window. However - in the diagram immediately adjacent to it, in the "profile offsets" panel, someone has made the decision that this diagram will show a simplified typical window shape. So why the inconsistency between these two illustrations, that appear next to each other in the same interface? If the "preview" image showed a simplified window-type shape, just like the other one does, I think that would go a long way towards making it more immediately apparent what's being shown.

     

    You're right - it's because wall closures can apply to not only doors and windows but also symbols and theoretically any plug-in object that wants to opt into the system.  So we needed to keep the preview vague (at least at the wall style level - as I said, it would be much better to show something closer to the actual insert at the insert level if possible).  But there was actually another reason for this - performance.  These settings are far too complex to try to fake up a preview that accurately represents what will happen when you apply them to a real object in a real wall, so we make the preview by actually creating a real object in a real wall and showing what the system really spits out.  This entails some complex geometric operations with solids and sectioning solids, and it can easily get very slow if the preview object is too complex.  We considered it essential to be able to update the preview without the user perceiving any delay, because having to wait for the preview to regenerate after each keystroke in the dialog would be extremely annoying.  So keeping the preview object this simple also allows us to keep the dialog fast and usable.

    • Like 3
  10. 20 hours ago, line-weight said:

     

    I'm largely just quibbling about confusing/inconsistent terminology that is one of my bugbears, throughout the VW UI.

     

    But yes, in the preview (as far as I can make out)

    Insert Depth = overall depth of the window object (or other symbol) you are inserting, and you have to set this yourself

    Insert Origin = where, within the window object, not within the wall the insertion point for that window is, and you have to set this yourself

     

    As far as the insert location (the location within the thickness of the wall, where the window gets inserted) is concerned, settings you make within the wall closures dialogue are reflected in the preview but may or may not reflect reality, and settings you make in the plug-in object options dialogue aren't reflected in the preview and you can't manually add them to the preview yourself.

     

     

     

    This was an incredibly difficult part of the feature to design, because it has to be sufficiently general to work with not only our doors and windows, but also with every other door and window plug-in that exists, in countries where the settings are broken down completely differently and use entirely different terminology.  This was the compromise that left everyone with something usable but was not ideal for anyone.

  11. 21 hours ago, line-weight said:

    Having had a brief look in VW2024, this is still the same there - is that right?

     

    This is really a major source of confusion because if I decide that the wall closure settings for a certain window are going to be determined by that window, not by the wall's "suggestions", and untick the "use wall settings" box in the window's OIP, if I start interacting with settings offered to me for that window instance it seems reasonable to assume that any adjustments I make in those settings will apply to that window instance.

     

    Basically, yes.  It is something I would still like to improve if we have time, but that got less important with the new Vectorworks 2024 ability to define multiple wall closures for each wall/wall style.  The reason is that that ability makes it far less likely that you will need to override wall closure settings for an individual insert.  The intended workflow is that you will define all the closures you will need for a given wall style in the style itself.  Of course there are always exceptions and one-offs, so we did not remove the ability to override the closure settings at the insert level, but you will notice we did remove the ability to override the wall style closure settings at the wall object level, because there is no real need for it, and having those multiple levels of overrides along with multiple wall closures would be incredibly confusing.

     

  12. As Matt was alluding to, there is no way to indicate in the component or closure settings of a wall or wall style whether the insert location will be observed, because that is a choice made by each individual insert.  In any given wall some inserts might be using the wall's insert location, some might be using the wall's closure's insert location, some might be overriding the wall's closure configuration with a custom one with its own insert location and using that, and some might be set to other locations individually.  This can seem very complicated at first, but it makes a lot of sense once you figure it out, and you won't need to go digging into all these options every time.

     

    Think of it this way - a wall insert always directly controls its own insert location, just like it always did.  You set that from the "Insert" field on the Object Info palette, in the familiar place.  Additionally, any place you are defining a wall component structure (the main components or the wall closure settings of a wall or wall style), you can designate an insert location that makes sense and might be useful for that particular structure.  But it is up to each insert whether it wants to use that or make some other choice for itself.  The wall offers logical suggestions, but the insert itself is always in control, just like it always was.  When you are editing a wall style, wall, or wall closure, all you are doing is editing those logical suggestions that the insert might or might not choose to utilize.  That is why the preview of the insert object is generic in those places - because it is not any specific actual insert, but rather represents any possible insert.

     

    As Matt also mentioned, the one place this preview could actually be more realistic is in the Wall Closure dialog for a specific insert that is actually in a wall in the document.  Since we have an actual wall and an actual insert, we could try to show the situation exactly as it really is in the document.  I have experimented with this, and practically speaking it actually has some unexpected difficulties and works less well than you might expect in a lot of cases.  But one thing we could do is try to set the the insert depth and insert origin preview options to automatically reflect the real insert as well as possible.  In fact, we should already be doing this, I just haven't gotten it to work properly yet.

     

    But actually, the ultimate goal of this feature is to create a situation where you almost never have to go into the wall closure settings of an individual insert or dive into any of these settings while modeling.  Rather, you set up your wall styles, you set up your door and window styles, and then you just drag them into different kinds of walls and they all get the right closure settings and insert locations automatically.  We are not finished with this feature yet, and we've got some nice improvements coming up that should make all this even more usable.

    • Like 3
  13. Wall, slab, and roof styles will definitely purge, but one thing to check is whether a style is selected in the preferences for that tool, because in that case the Purge command will not delete it.  For example, if you create two wall styles, "WallStyle-1" and "WallStyle-2", and then you go to the Wall tool and select "WallStyle-1" in the tool's mode bar, then run the Purge command, it will purge "WallStyle-2" but not "WallStyle-1".  And then any resources (materials, hatches, textures, etc.) used by that wall style will not purge.  And then any resources used by those resources (hatches and textures of a material, for example) will also not purge.  So that can leave quite a few resources unpurged.  Could that be what is happening here?

    • Like 2
  14. Hi cberg,

     

    This is a bug that will be fixed in the next service pack.  It happened as a result of the work we did that creates true 3D subobjects for walls, allowing you to convert a wall to a group of 3D solid objects.  Because those 3D objects are inside the wall, the tool was accidently picking into the wall and getting the solid object inside and modifying that.  But when the wall is changed and the geometry is recreated, this accidental edit vanishes.  Sorry for the confusion!

    • Like 3
  15. 2 hours ago, line-weight said:

    What's shown in these videos often bears no resemblence to what actually happens in the real software. So who knows if we should read anything into this. But my first reaction is that the layers in this wall don't make any sense constructionally, other than wrapped internal and external finishes which would certainly be good to have eventually.

     

    1307783403_Screenshot2021-09-07at22_03_25.jpg.46410baa03f575dc112054543366a7a1.jpg

     

     

     

    It would be good to have those eventually!  How about for Vectorworks 2022?

    • Like 4
  16. Hi everyone,

     

    As you know, this bug has been extremely difficult to diagnose, and we could not even find a way to consistently reproduce it.  But thanks to the help you have provided in this thread, we have finally figured out what is happening.  We have a fix for it that we are testing now, and hopefully that should be available in Vectorworks 2019 Service Pack 4.  However, I wanted to give you a little more information about it so that you can avoid this bug in the meantime.

     

    Unfortunately, the bug is not caused by doing any one thing, but by a combination of actions that result in a specific condition.  To avoid this bug, the condition you need to avoid is indirectly editing a Wall Style by editing a resource it uses, checking out one or more walls of that Wall Style while not checking out all the walls they are joined to, and then doing a Save and Commit.

     

    For example, suppose you have a Wall Style called WallStyle-1, which has a component that uses a class called Class-1.  Suppose you also have a wall of WallStyle-1 joined to other walls (either of the same Wall Style, a different Wall Style, or Unstyled).  If you edit Class-1, that indirectly edits WallStyle-1, because it uses Class-1.  If you then change the Caps setting of the wall of WallStyle-1 in the Object Info Palette, this will check out that wall.  Then, the next time you Save and Commit, the joins between that wall and the walls it is joined to will be broken in the project file (but will continue to be fine in the working file in which you made the edit, which is why it was difficult to know the bug had occurred).

     

    To avoid this, you can separate your resource edits and your object edits into different Save and Commits.  So, if you need to edit any classes, hatches, gradients, images, gradients, tiles, Line Types, or textures that may be used in a Wall Style, first Save and Commit, to commit any outstanding object edits to the project file.  Then edit whatever resources you need to edit and Save and Commit again to commit those resource edits to the project file.  Then you can continue to make object edits without a problem.

     

    Note that if you directly edit a Wall Style itself, it will check out all the walls of that Wall Style and any walls they are joined to, so the bug will never occur in this case.

     

    Once the fix comes out, you will not have to worry about any of this, and you can edit whatever you want and Save and Commit whenever you want.  The description above is only important if you want to avoid the bug in Vectorworks 2019 Service Pack 3 or earlier.  If you have any questions, please let me know.

     

    @Matt Panzer @Sam stork @JMR

    • Like 4
×
×
  • Create New...