V2023 wall issue with windows/doors

[fabrica]

getting consistent crashes when moving doors / windows around in walls with components with 2023.

- especially with duplicate copy of a door or changing window heights - will cause a crash

- changing a window height (if more than one window in wall) will result in windows disappearing in 3d view - but show fine in plan view.

 

below is sliding door at 2600mm high - changed to 2650mm high and both disappear in 3d. (all looks ok in 2d)

(on MacBook Pro 14", OS 12.6)

[SGSF 42]

Here you are Matt

The Whitehouse OPTION 5 rev A.vwx

[Matt Panzer]

1 hour ago, SGSF 42 said:

Here you are Matt

The Whitehouse OPTION 5 rev A.vwx 11.39 MB · 0 downloads

 

Thanks for the file.  I do see the openings after opening the file in VW 2023 SP1 so there must be some action that causes the issue.

When you brought the file to 2023, did you see the problem right away?  If not, any idea what you were doing before you noticed it?

[NH21]

I'm having the same problem with a file I started in VW 2023. I've found that I only have the "disappearing window/door" issue when there's more than one in a single wall. As of yet, I haven't figured out what triggers it to occur; the windows show up fine at first and then (usually after working on the sheet layers for a while) I suddenly realize they've disappeared in 3d view. If I split the wall so that each window is in it's own wall segment, the windows appear in 3d as well as in plan view, but then I end up with vertical lines at the wall splits in my hidden line renderings. So it's not a good workaround in terms of construction documents looking correct.

[bhkkhb]

Also having significant issues with this, including it crashing my VW 2023. 

[rDesign]

I just had this happen to me in a file that I've been working in Vw2023 SP1 for awhile now (converted from Vw2022).

 

The previously mentioned fix of moving the wall 0,0 does not regenerate the wall. Even if I drag one of the windows out of the wall and back in, it will not cut the opening. I tried changing the Window Style so that it would regenerate the windows, but that didn't fix it either. 

 

@Matt Panzer any suggestions on how to fix this?

 

Of course things like this always happen when you're on a deadline...

[lillyTe]

Same problem too.. SO FRUSTRATING... i change the top of the window to round.. all windows disappear . TERRIBLY ANNOYING. Same problem too.. SO FRUSTRATING... i change the top of the window to round.. all windows disappear . TERRIBLY ANNOYING. 

[Pat Stanford]

If this is repeatable in that file, please enter a bug report, include the file, and give explicit steps of how to reproduce the issue.

 

I'm sorry you are having the problem, but it is only effecting a few people and it appears it has been very hard to get a reproducible case to allow the root of the problem to be found.

[E|FA]

Another clue for @Matt Panzer?

[rDesign]

Cross-linking threads discussing the same bug:

 

[Matt Panzer]

On 7/3/2023 at 6:33 PM, lillyTe said:

Same problem too.. SO FRUSTRATING... i change the top of the window to round.. all windows disappear . TERRIBLY ANNOYING. Same problem too.. SO FRUSTRATING... i change the top of the window to round.. all windows disappear . TERRIBLY ANNOYING. 

 

Would it be possible to PM (private message) me the file with steps to reproduce?

[dhaun]

I WAS having this same issue: IT SEEMS THAT TOGGLING "CREATE NICHE FOR SPACE OBJECTS" AFFECTS THIS AND MUST BE CHECKED, NOT UNCHECKED.

 

problem description below:

 

I can see doors and windows in plan, and wireframe. In shaded, and in my building elevations, sections, etc. some appear correctly, and some do not. I can still select an unseen window in shaded , VW knows it is there, it is just not making the "hole" in the wall / showing the window. In some cases, the jamb(?) is displayed, nothing else. I have droppered settings from a properly displaying window to one that is not, cloning it, and it does not fix. I have made sure all objects are "in wall" and full break with caps, does not fix. It seems to be consistent within a wall, once one is broken, all within that wall are broken. It seems to be spreading, and getting worse - making my elevations into blank boxes devoid of windows and doors.

[dhaun]

ACTUALLY, SIMPLY TOGGLING IT ON/OFF SEEMS TO REPAIR, hopefully permanently. I presume this still needs attention from VW, Matt Panzer.

[grahamcase]

Just wanted to jump in to say that I am also having this issue in VW2023 with a file that was started in VW2023. Same issue - if more than one object is attached to a wall, they all graphically disconnect, while still saying in the OIP that they are "in wall". So if I have more than one door in a single wall, they "become disconnected" yet still say in the OIP that they are "Doors in Wall". This issue was not always present in this file, indeed it just cropped up into the file today!

 

More than just doors/windows, though, if I have a door in a wall (Wall A) and another wall (Wall B) is T-Joined to Wall A, the same graphical issue will happen to the door located in Wall A. Does not appear to be an issue with L-Joined walls.

 

The easiest solution is to split walls that have long runs and multiple doors, and just not T-Join other walls, but this is a nonsense solution, I think we can all agree.

 

Unfortunately, neither dhaun's solution, to toggle on/off the "Create Niche for Space Objects" does not solve this issue, nor @Matt Panzer's Move by (0,0) trick work for me.

 

ONE THING I HAVE NOTICED, in both my drawings and the examples I've seen in this post is that when this issue happens, VW creates a strange line in the Wall Geometry at the midpoint between the two cutting objects. This is visible in 3D modes only in wireframe, so understandable that it seems no one has noticed. I have attached screenshots to demonstrate. In both images, the wall is a single wall, no splits. In the "working as intended" example, you see a clean wall (in 3D) with no unnecessary lines - just two doors hosted in the wall. In the "problem" image, you see a strange line at the midpoint between the two hosted doors. It looks like a split in the wall, however it is an artifact produced by the issue causing the graphical glitch. I have also attached a Birdseye wireframe view of the glitch - the line you see that looks like a split in the walls should not be there: that is a single wall, and not two separate walls.

 

Sorry to be so verbose, I just want to emphasize this issue.

 

I hope that this helps the VW team pinpoint and solve this issue. I am happy to DM my file if someone on the VW team feels that would help.

 

Graham

[grahamcase]

To follow-up from yesterday. Without closing Vectorworks last night when I went home (though I did close the file), I came into work today to output some drawings. The graphical issue persisted through a save, however when I needed to add a new door the graphical issue did not occur for the newly added geometry. I was also able to fix the existing issue in the file, though the same process failed for me yesterday

 

I worry that this issue will persist, as it seems to be intermittent, short-term, with no sensible way to fix it, until VW decides it's no longer an issue.

[Matt Panzer]

19 hours ago, grahamcase said:

To follow-up from yesterday. Without closing Vectorworks last night when I went home (though I did close the file), I came into work today to output some drawings. The graphical issue persisted through a save, however when I needed to add a new door the graphical issue did not occur for the newly added geometry. I was also able to fix the existing issue in the file, though the same process failed for me yesterday

 

I worry that this issue will persist, as it seems to be intermittent, short-term, with no sensible way to fix it, until VW decides it's no longer an issue.

 

Hi @grahamcase and thank you for all the detailed information.  We're working very hard to solve this issue but finding the "smoking gun" for it is proving very difficult.  We believe it may be due to an issue with a third party library and are looking into that now.  Ideally, if we can have a reproducible case starting from a new blank document, that would give us the best clue how things get into this state.  The reason this is so difficult is that the issue goes unnoticed when it actually happens because it's not visible to users until something causes a reset to the wall or a wall insert.  If the affected wall/insert does not get reset for weeks, it makes it impossible to determine what caused it when it finally shows itself.  Well keep pushing on this until we get this resolved.

[grahamcase]

4 hours ago, Matt Panzer said:

 

Hi @grahamcase and thank you for all the detailed information.  We're working very hard to solve this issue but finding the "smoking gun" for it is proving very difficult.  We believe it may be due to an issue with a third party library and are looking into that now.  Ideally, if we can have a reproducible case starting from a new blank document, that would give us the best clue how things get into this state.  The reason this is so difficult is that the issue goes unnoticed when it actually happens because it's not visible to users until something causes a reset to the wall or a wall insert.  If the affected wall/insert does not get reset for weeks, it makes it impossible to determine what caused it when it finally shows itself.  Well keep pushing on this until we get this resolved.

 

Thanks for the quick follow up, Matt! To clarify my wording when I said "...until VW decides it's no longer an issue" I literally meant the program, and not the company or the people (like yourself) working on it, so sorry if my wording was perceived as dismissive in any way. I fully recognize this is one of those issues that are almost impossible to solve because it's so intermittent - while it's frustrating from an en-user standpoint, I can only imagine that it has caused a few bald spots on the developer side from it's insistence on not being consistent.

 

FWIW, visually (from the door appearing not to be hosted and with that strange line at the midpoint of cutting objects) it seems like the walls are doubling back on themselves, and meeting at the midpoint between cutting objects - the program then sees the cutting objects cutting through one part of the wall (so showing up as an object in a wall in the OIP), but since the object can't cut through more than one wall, it gets covered by the part of the wall that has doubled back. Anyway, that's just my theory, and offers no help why the wall might do that!

 

Thanks again!

[Matt Panzer]

2 hours ago, grahamcase said:

To clarify my wording when I said "...until VW decides it's no longer an issue" I literally meant the program, and not the company or the people (like yourself) working on it, so sorry if my wording was perceived as dismissive in any way. 

 

LOL!  Thanks for the clarification.  Luckily, I didn't read it that way so no worries.

 

Thanks for your theories.  I've had many myself and anything and everything (no matter how ridiculous they might sound) is always worth considering.  And I'm not suggesting your theory sounds ridiculous.  🙂 

 

That all aside, I DO HAVE AN UPATE:

I believe we have zeroed in on the cause of this which is huge considering we still cannot come up with steps to reproduce the problem.  To put it simply, we believe the issue happens during multi-threading where one thread is changing a something that can have an affect on the geometry that another thread is working on.  If this is the case, it is a very complex situation and I cannot even act like I even know what I'm talking about (so I'll stop here).  All I will say is that we're hopeful but it may take some time to find the possible places this bug is hiding between threads.

[rDesign]

3 hours ago, Matt Panzer said:

To put it simply, we believe the issue happens during multi-threading where one thread is changing a something that can have an affect on the geometry that another thread is working on.  If this is the case, it is a very complex situation and I cannot even act like I even know what I'm talking about (so I'll stop here).

That’s promising that you have an idea of what might be causing it; hopefully the solution is not to take everything back to single-threads — which would be unfortunate. 

[Matt Panzer]

29 minutes ago, rDesign said:

That’s promising that you have an idea of what might be causing it; hopefully the solution is not to take everything back to single-threads — which would be unfortunate. 

I don’t even think that would be considered. 🙂